Sunday, October 26, 2014

SQL1220N The database manager shared memory set cannot be allocated

I faced this error while using db2 on Ubuntu 12.04 desktop, When tried to start instance it failed as below.

SQL1220N

The database manager shared memory set cannot be allocated.

The term shared memory is a term used to describe a type of memory management in the Unix kernel.  It is a memory region that can shared between different processes. Using a shared memory model, this avoids creating duplicate copies of memory.  So programs can eaily share data.
SHMMAX is just the maximum size of a single shared memory segment.  It’s size is represented in bytes”.

By default SHMMAX is 32 MB , Here db2 database manager wasn't able to start the instance with existing SHMMAX value use cat /proc/sys/kernel/shmmax to find out current value, so What we do is increase the value

Place an entry in /etc/sysctl.conf like kernel.shmmax=500000000, which is around 500MB just restart the machine and we are good to go. If not working increase it to 1 gb or more.

db2inst1@ubuntu:~$ db2start
10/26/2014 18:50:07     0   0   SQL1063N  DB2START processing was successful.
SQL1063N  DB2START processing was successful.

Wednesday, September 17, 2014

db2_install or db2icrt or db2setup fails with memory corruption error on Ubuntu OS

While i started installation of DB2 data server trail v 10.1 FP0 i got struck with memory corruption error and wasn't able to move forward in installation. So solution to this problem is to install RPM package or else need to move to next fix pack level 1 FP1.

Problem :



db2inst1@ubuntu:~/server$ sudo ./db2setup  

DBI1190I  db2setup is preparing the DB2 Setup wizard which will guide
      you through the program setup process. Please wait.


*** glibc detected *** /tmp/db2.tmp.2521/db2/linuxamd64/install/../java/jre/bin/java: malloc(): memory corruption: 0x00007f35880c0ab0 ***
======= Backtrace: =========
/lib/x86_64-linux-gnu/libc.so.6(+0x7ec66)[0x7f358f61dc66]
/lib/x86_64-linux-gnu/libc.so.6(+0x80e2b)[0x7f358f61fe2b]
/lib/x86_64-linux-gnu/libc.so.6(__libc_malloc+0x75)[0x7f358f6220b5]
/usr/lib/x86_64-linux-gnu/libstdc++.so.6(_Znwm+0x1d)[0x7f356f98dded]




 Solution : sudo apt-get install rpm
 
Here is the problem document from IBM link :

http://www-01.ibm.com/support/docview.wss?uid=swg21611103

Monday, July 28, 2014

Stop Q Replication in a Right Way

Everyone must understand the importance of proper way to stop Q replication.
I bet you that your setup will not work properly if you don't do that right way, after many tests personally i prefer the below way to my stop my replication safely.



steps:


A) stop the capture and apply programs that are running


asnqccmd capture_server=TESTA capture_schema=ASNUA
asnqacmd apply_server=TESTB apply_schema=ASNUB

B) stop the listener and channels


We need to login into queue manager to stop the listener and channels

db2inst1@sairam:~/setup$ runmqsc QMUA
5724-H72 (C) Copyright IBM Corp. 1994, 2011.  ALL RIGHTS RESERVED.
Starting MQSC for queue manager QMUA.
stop listener(REPL_LSTR)
     1 : stop listener(REPL_LSTR)
AMQ8706: Request to stop WebSphere MQ Listener accepted.
stop channel(QMUA_TO_QMUB)
     2 : stop channel(QMUA_TO_QMUB)
AMQ8019: Stop WebSphere MQ channel accepted.
stop channel(QMUB_TO_QMUA)
     3 : stop channel(QMUB_TO_QMUA)
AMQ8019: Stop WebSphere MQ channel accepted.
end
     4 : end
4 MQSC commands read.
No commands have a syntax error.
All valid MQSC commands were processed.

db2inst1@sairam:~/setup$ runmqsc QMUB
5724-H72 (C) Copyright IBM Corp. 1994, 2011.  ALL RIGHTS RESERVED.
Starting MQSC for queue manager QMUB.
stop listener(REPL_LSTR)
     1 : stop listener(REPL_LSTR)
AMQ8706: Request to stop WebSphere MQ Listener accepted.
stop channel(QMUA_TO_QMUB)
     2 : stop channel(QMUA_TO_QMUB)
AMQ9533: Channel 'QMUA_TO_QMUB' is not currently active.
stop channel(QMUB_TO_QMUA)
     3 : stop channel(QMUB_TO_QMUA)
AMQ8019: Stop WebSphere MQ channel accepted.
end
     4 : end
4 MQSC commands read.
No commands have a syntax error.
All valid MQSC commands were processed.

C) stop the queue managers


db2inst1@sairam:~/setup$ endmqm QMUA
Quiesce request accepted. The queue manager will stop when all outstanding work
is complete.
db2inst1@sairam:~/setup$ endmqm QMUB
Quiesce request accepted. The queue manager will stop when all outstanding work
is complete.

Thinking complicated ? I do this every time and everyday but i prepared a shell script to do all these. Same way i have a script to start the replication...  feeling easy :)

########## START ###############
#input file(inputs) for the stop script(stop_qm)
stop listener(REPL_LSTR)
stop channel(QMUA_TO_QMUB)
stop channel(QMUB_TO_QMUA)
######### END #################

########## START #############################
#Put below lines a script and execute it from normal command line as a shell script
#to stop capture and apply programs
asnqccmd capture_server=TESTA capture_schema=ASNUA
asnqacmd apply_server=TESTB apply_schema=ASNUB
#allow capture and apply programs to go down properly and execute next command i will SLEEP FOR 10 secs
sleep 10
#to stop listener and channels use a input file(inputs) to the queue manager
runmqsc QMUA < $1
runmqsc QMUB < $1
#stop queue managers
endmqm QMUA
endmqm QMUB
########## END ###############################


Now let us execute the script

sh stop_qm inputs

Quick setup of Unidirectional Q Replication between two DB2 databases

Its been many days that i blogged, and today I have enough time to write on DB2 Unidirectional Q Replication between two DB2 databases.

Q Replication is high availability concept in DB2 , used to replicate data from one database to another database.Today i will show a practical demonstration on how to setup DB2 Unidirectional replication between 2 DB2 databases. Unidirectional replication is nothing but replicating data only in ONE direction. High level picture of my setup is as below.



Required:

Test box installed with DB2 V9.7 and Websphere MQ V7.1 and 2 databases created TESTA, TESTB

High level steps:

1) Create necessary Websphere MQ objects to setup unidirectional replication
2) Create control tables needed for capture and apply servers
3) Create Replication Queue map
4) Create a subscription and start capture and apply programs and populate the data to observe replication setup

Create Websphere MQ objects : We need certain objects to enable us to setup replication in unidirectional between two databases, check the script below and make necessary changes according the machine details

ASNCLP SESSION SET TO Q REPLICATION;
CREATE MQ SCRIPT CONFIG TYPE U
MQSERVER 1 NAME TESTA MQHOST "sairam"  MQPORT 2510 QMANAGER QMUA QNAME_QUAL ASNUA,
MQSERVER 2 NAME TESTB MQHOST "sairam" MQPORT 2511 QMANAGER QMUB QNAME_QUAL ASNUB;

Put in a file and run it with asnclp command line as below it will create 2 batch files and 2 script files we shall use scripts as were are in linux environment, grant execute permission for the scripts and execute them

asnclp -f create_mqobjects

db2inst1@sairam:~/setup$ ls -lrt
-rw-rw-r-- 1 db2inst1 db2inst1 3931 Jul 28 13:17 qrepl.testa.mq_windows.bat
-rw-rw-r-- 1 db2inst1 db2inst1 3922 Jul 28 13:17 qrepl.testa.mq_aixlinux.sh
-rw-rw-r-- 1 db2inst1 db2inst1 3976 Jul 28 13:17 qrepl.testb.mq_windows.bat
-rw-rw-r-- 1 db2inst1 db2inst1 3967 Jul 28 13:17 qrepl.testb.mq_aixlinux.sh

chmod 755 qrepl.testa.mq_aixlinux.sh qrepl.testb.mq_aixlinux.sh

db2inst1@sairam:~/setup$ ./qrepl.testa.mq_aixlinux.sh 
There are 19 days left in the trial period for this copy of WebSphere MQ.
WebSphere MQ queue manager created.
Directory '/var/mqm/qmgrs/QMUA' created.
The queue manager is associated with installation 'Installation1'.
Creating or replacing default objects for queue manager 'QMUA'.
Default objects statistics : 71 created. 0 replaced. 0 failed.
Completing setup.
Setup completed.

db2inst1@sairam:~/setup$ ./qrepl.testb.mq_aixlinux.sh 
There are 19 days left in the trial period for this copy of WebSphere MQ.
WebSphere MQ queue manager created.
Directory '/var/mqm/qmgrs/QMUB' created.
The queue manager is associated with installation 'Installation1'.
Creating or replacing default objects for queue manager 'QMUB'.
Default objects statistics : 71 created. 0 replaced. 0 failed.
Completing setup.
Setup completed.

By the end of this you will see two queue manager up and running, check using command

db2inst1@sairam:~/setup$ dspmq
QMNAME(QMUA)                                              STATUS(Running)
QMNAME(QMUB)                                              STATUS(Running)

Create control tables for capture and apply servers and Replication Queue Map : The control tables at the Q Capture server contain information about data sources, options for Q subscriptions or publications, operating parameters for the Q Capture program, Q Capture performance statistics, and other metadata. The control tables at the Q Apply server contain Q Apply operating parameters, Q subscription definitions, performance statistics, and other metadata. Replication Queue Map, which identifies the WebSphere MQ queues on both servers that are used to communicate between the servers.

I will add 2 and 3 steps in same script as show below to create control tables for capture and apply and replication queue map

asnclp session set to q replication;
set server capture to dbalias TESTA dbname TESTA id "db2inst1" password "db2inst1";
set server target to dbalias TESTB dbname TESTB id "db2inst1" password "db2inst1";

set capture schema source ASNUA;
set apply schema ASNUB;
set qmanager QMUA for capture schema;
set qmanager QMUB for apply schema;
set run script now stop on sql error on;

create control tables for capture server using mqdefaults;
create control tables for apply server ;
create replqmap ASNUA_TO_ASNUB using mqdefaults;

Put the commands in a file and run it with asnclp command line, please observe that all objects are created successfully, you should see a line after execute successful execution of command when you execute script

asnclp -f crt_rest

ASN1514I  The replication action ended at "Monday, 28 July, 2014 1:23:10 PM IST" with "1" successes, "0" errors, and "0" warnings.
<ClpInfo2Log:: The SQL command completed successfully.>


Create a subscription and start capture and apply programs and populate the data to observe replication setup:

create a table customer in db2inst1 schema in both database before hand and Use the below script that creates a unidirectional subscription for table DB2INST1.CUSTOMER

ASNCLP SESSION SET TO Q REPLICATION;
set server capture to dbalias TESTA dbname TESTA id "db2inst1" password "db2inst1";
set server target to dbalias TESTB dbname TESTB id "db2inst1" password "db2inst1";

set capture schema source ASNUA;
set apply schema ASNUB;

set qmanager QMUA for capture schema;
set qmanager QMUB for apply schema;
set run script later;
set output capture script newsubcap;
set output target script newsubapp;
create qsub subtype U using replqmap ASNUA_TO_ASNUB ( SUBNAME CUSTOMER-UNI DB2INST1.CUSTOMER EXIST TARGET NAME DB2INST1.CUSTOMER);  

Put above lines into a files and run it with asnclp command line to create one subscription

asnclp -f sub_customer

Now lets start the capture program and apply program:

nohup asnqcap capture_server=TESTA capture_schema=ASNUA &
nohup asnqapp apply_server=TESTB apply_schema=ASNUB &

Connect to source database TESTA and populate one row and check it on target database TESTB

db2inst1@sairam:~/setup$ db2 connect to testb

   Database Connection Information

 Database server        = DB2/LINUXX8664 9.7.9
 SQL authorization ID   = DB2INST1
 Local database alias   = TESTB

db2inst1@sairam:~/setup$ db2 "insert into customer values(1,'Murali','bhatiagardens')"
DB20000I  The SQL command completed successfully.
db2inst1@sairam:~/setup$ db2 "select * from customer"

ID         CUSTNAME             CUSTADD             
---------- -------------------- --------------------
1          Murali               bhatiagardens       

  1 record(s) selected.

db2inst1@sairam:~/setup$ db2 connect to testb

   Database Connection Information

 Database server        = DB2/LINUXX8664 9.7.9
 SQL authorization ID   = DB2INST1
 Local database alias   = TESTB

db2inst1@sairam:~/setup$ db2 "select * from customer"

ID         CUSTNAME             CUSTADD             
---------- -------------------- --------------------
1          Murali               bhatiagardens       

  1 record(s) selected.

We shall do a reverse test that is populate a row on target side and observe it don't replicate to source database. :p

db2inst1@sairam:~/setup$ db2 connect to testb

   Database Connection Information

 Database server        = DB2/LINUXX8664 9.7.9
 SQL authorization ID   = DB2INST1
 Local database alias   = TESTB

db2inst1@sairam:~/setup$ db2 "insert into customer values(2,'Rupesh','hyderabad')"
DB20000I  The SQL command completed successfully.

db2inst1@sairam:~/setup$ db2 "select * from customer"

ID         CUSTNAME             CUSTADD             
---------- -------------------- --------------------
1          Murali               bhatiagardens       
2          Rupesh               hyderabad           

  2 record(s) selected.

db2inst1@sairam:~/setup$ db2 connect to testa

   Database Connection Information

 Database server        = DB2/LINUXX8664 9.7.9
 SQL authorization ID   = DB2INST1
 Local database alias   = TESTA

db2inst1@sairam:~/setup$ db2 "select * from customer"

ID         CUSTNAME             CUSTADD             
---------- -------------------- --------------------
1          Murali               bhatiagardens       

  1 record(s) selected.

So that's it for the day and by the end of the post we have clearly defined source and target and created a setup and populated the data to show its working as expected. Readers please post your comments and doubts and any suggestions. I'm Happy to help you anytime. Good BYE

Please feel to write to me saimurali619@gmail.com for any queries and help.

Tuesday, July 1, 2014

Migration of db2 v9.7 to v10.1 / Upgrade of DB2 v9.7 to v10.1

Migration of db v9.7 to v10.1

1) First run db2ckupgrade to find out if we are allowed to migrate the instance to 10.1 level
2) After db2ckupgrade is successful, stop the instance and install the db2 v10.1 binaries
3) We now upgrade the instance code level to 10.1 using command db2iupgrade
4) once instance level has been upgraded we need to upgrade the databases under that instance

STEP 1

db2inst1@sairam:~/software/server$ ./db2ckupgrade -e -l /home/db2inst1/logfile -u db2inst1 -p db2inst1
DBT5508I  The db2ckupgrade utility completed successfully. The database or databases can be upgraded.

db2inst1@sairam:~/software/server$ more ~/logfile 
Version of DB2CKUPGRADE being run: VERSION "10.1"

Database: "SAMPLE"

DBT5537I  The db2ckupgrade utility has completed processing for database "SAMPLE".

DBT5508I  The db2ckupgrade utility completed successfully. The database or databases can be upgraded.

db2inst1@sairam:~/software/server$ db2ls

Install Path                       Level   Fix Pack   Special Install Number   Install Date                  Installer UID
---------------------------------------------------------------------------------------------------------------------
/opt/ibm/db2/V9.7                 9.7.0.9        9                            Tue Jul  1 16:48:02 2014 IST             0
db2inst1@sairam:~/software/server$
db2inst1@sairam:~/software/server$

db2inst1@sairam:~/software/server$ db2stop
01/07/2014 18:03:05     0   0   SQL1064N  DB2STOP processing was successful.
SQL1064N  DB2STOP processing was successful.

db2inst1@sairam:~/software/server$ ls -lrt
total 64
-r-xr-xr-x  1 db2inst1 db2inst1 5154 May 15 16:55 db2prereqcheck
-r-xr-xr-x  1 db2inst1 db2inst1 5154 May 15 16:55 db2setup
-r-xr-xr-x  1 db2inst1 db2inst1 5172 May 15 16:55 db2_install
-r-xr-xr-x  1 db2inst1 db2inst1 5136 May 15 16:55 db2ls
-r-xr-xr-x  1 db2inst1 db2inst1 5302 May 15 16:55 db2_deinstall
-r-xr-xr-x  1 db2inst1 db2inst1 5190 May 15 16:56 installFixPack
-r-xr-xr-x  1 db2inst1 db2inst1 5349 May 15 16:56 db2ckupgrade
drwxr-xr-x 28 db2inst1 db2inst1 4096 May 15 16:56 doc
drwxr-xr-x  6 db2inst1 db2inst1 4096 May 15 16:56 db2

STEP 2

db2inst1@sairam:~/software/server$ sudo ./db2_install 
............................................
......................................
.......................
The execution completed successfully.

For more information see the DB2 installation log at
"/tmp/db2_install.log.52793".

db2inst1@sairam:~/software/server$ db2ls

Install Path                       Level   Fix Pack   Special Install Number   Install Date                  Installer UID
---------------------------------------------------------------------------------------------------------------------
/opt/ibm/db2/V9.7                 9.7.0.9        9                            Tue Jul  1 16:48:02 2014 IST             0 
/opt/ibm/db2/V10.1               10.1.0.4        4                            Tue Jul  1 18:08:00 2014 IST             0 

STEP 3

db2inst1@sairam:/opt/ibm/db2/V10.1/instance$ sudo ./db2iupgrade db2inst1
DBI1446I  The db2iupgrade command is running.

DB2 installation is being initialized.

 Total number of tasks to be performed: 4
Total estimated time for all tasks to be performed: 309 second(s)

Task #1 start
Description: Setting default global profile registry variables
Estimated time 1 second(s)
Task #1 end

Task #2 start
Description: Initializing instance list
Estimated time 5 second(s)
Task #2 end

Task #3 start
Description: Configuring DB2 instances
Estimated time 300 second(s)
Task #3 end

Task #4 start
Description: Updating global profile registry
Estimated time 3 second(s)
Task #4 end

The execution completed successfully.

For more information see the DB2 installation log at
"/tmp/db2iupgrade.log.23052".
DBI1070I  Program db2iupgrade completed successfully.

db2inst1@sairam:~$ db2level
DB21085I  This instance or install (instance name, where applicable:
"db2inst1") uses "64" bits and DB2 code release "SQL10014" with level
identifier "0205010E".
Informational tokens are "DB2 v10.1.0.4", "s140509", "IP23584", and Fix Pack
"4".
Product is installed at "/opt/ibm/db2/V10.1".

db2inst1@sairam:~$ db2 list db directory

 System Database Directory

 Number of entries in the directory = 1

Database 1 entry:

 Database alias                       = SAMPLE
 Database name                        = SAMPLE
 Local database directory             = /home/db2inst1
 Database release level               = d.00
 Comment                              =
 Directory entry type                 = Indirect
 Catalog database partition number    = 0
 Alternate server hostname            =
 Alternate server port number         =

db2inst1@sairam:~$ db2level
DB21085I  This instance or install (instance name, where applicable:
"db2inst1") uses "64" bits and DB2 code release "SQL10014" with level
identifier "0205010E".
Informational tokens are "DB2 v10.1.0.4", "s140509", "IP23584", and Fix Pack
"4".
Product is installed at "/opt/ibm/db2/V10.1".

db2inst1@sairam:~$ db2start
07/01/2014 18:14:31     0   0   SQL1063N  DB2START processing was successful.
SQL1063N  DB2START processing was successful.

db2inst1@sairam:~$ db2 connect to sample
SQL5035N  The database must be upgraded to the current release.  
SQLSTATE=55001

STEP 4

db2inst1@sairam:~$ db2 upgrade db sample

DB20000I  The UPGRADE DATABASE command completed successfully.

db2inst1@sairam:~$ db2 connect to sample

   Database Connection Information

 Database server        = DB2/LINUXX8664 10.1.4
 SQL authorization ID   = DB2INST1
 Local database alias   = SAMPLE

db2inst1@sairam:~$ 

Monday, June 30, 2014

Installation methods of DB2 on Linux/Unix

Installation methods of DB2 on Linux/Unix - There are 4 methods, i will take this in a detailed with practical examples.

1) db2setup

The DB2 Setup wizard is a GUI installer available on Linux, UNIX, and Windows operating systems. The DB2 Setup wizard provides an easy-to-use interface for installing DB2 products and for performing initial setup and configuration tasks.
note: On Linux and UNIX platforms, an X server is required to display the DB2 Setup wizard.
a) uncompress the v9.7fp9_linuxx64_server.tar file
b) cd server
c) sudo ./db2prereqcheck
d) sudo ./db2setup  - a GUI installer will be opened and you just need to run through the steps and complete, its pretty straightforward and easy process.



2) response file installation

a) A response file is a text file that contains setup and configuration values. The file is read by the DB2 setup program and the installation is performed according to the values that have been specified, this method of installation is also referred as silent installation as you dont need to interact during the installation process
using db2setup wizard we can generate a response file, benefit of this installation method is that you can create a response file without performing an installation and later change the options based on your requirement.
a) uncompress the v9.7fp9_linuxx64_server.tar file
b) cd server
c) sudo ./db2prereqcheck
d) sudo ./db2setup - a GUI installer will be opened and follow the steps.. at step number 4 we will have an "save my installation settings in a response file" ( No software will be installed ) - follow through rest of steps based on your requirement and you will finally get response file generated by the end of all steps.



e) sudo ./db2setup -r responsefile

b) Customizing the sample response files that are provided for each DB2 product , sample file will be found in below location you can see after untar and unzipping the file
server/db2/platform/samples , where < platform >is the platform that you are installing on
a) uncompress the v9.7fp9_linuxx64_server.tar file
b) cd server/db2/platform/samples ( here platform refers to your OS ) , here you can see sample response file
c) copy the sample to your custom location and make changes according to your requirements and the specific components that you want to install, use that edited file to install db2 product
d) sudo ./db2setup -r  db2aese.rsp_filename

3) db2_install command

The db2_install command installs all components for the DB2 product, but i doesnt perform user and group creation, instance creation .
a) uncompress the v9.7fp9_linuxx64_server.tar file
b) sudo ./db2prereqcheck
c) sudo ./db2_install   ( follow the response and complete the installation )

4) payload file deployment

This method is an advanced installation method that is not recommended for most users. It requires the user to physically install payload files. A payload file is a compressed tarball that contains all of the files and metadata for an installable component.
a) uncompress the v9.7fp9_linuxx64_server.tar file
b) cd server/db2/linuxamd64/FILES
c) now we need to untar needed components to the location /opt/ibm/db2/V9.7
d) now we will setup the fault monitor by running command   DB2DIR/bin/db2fmcu -u -p /etc/inittab  ( DB2DIR is the installation location your prouduct)
e) check which level of db2 installed using command db2greg -dump
f) create instance and setup profile file ..

First 3 ways of installation of db2 product is recommended for all users and 4th method is for most advanced users and is also not a recommend method of db2 product installation by IBM.

Let me know your comments and issues that you faced during DB2 installation on Unix and Linux. And 4th method is a very interesting one, let me know if any you faced any particular issues using 4th method.

Friday, June 27, 2014

Error SQL10013N SQLSTATE=42724 create wrapper for federation support

When we need to setup federation we need to first create a wrapper which will identify data source of the federated server.
We get this error SQL10013N as shown below, When we don't have Informix data source support installed in our server.



db2inst1@test-machine:~$ db2 "create wrapper drda"
DB21034E  The command was processed as an SQL statement because it was not a 
valid Command Line Processor command.  During SQL processing it returned:
SQL10013N  The specified library "libdb2drda.so" could not be loaded.  
SQLSTATE=42724

Below commands list the features that are installed on the server, we can seen there is no Informix Data Source Support Installed on the server

db2inst1@test-machine:~$ db2ls -q -b /opt/ibm/db2/V9.7

Install Path : /opt/ibm/db2/V9.7

Feature Response File ID             Level   Fix Pack   Feature Description
---------------------------------------------------------------------------------------------------------------------
BASE_CLIENT                         9.7.0.6          6   Base client support
JAVA_SUPPORT                        9.7.0.6          6   Java support
SQL_PROCEDURES                      9.7.0.6          6   SQL procedures
BASE_DB2_ENGINE                     9.7.0.6          6   Base server support
JDK                                 9.7.0.6          6   IBM Software Development Kit (SDK) for Java(TM)
COMMUNICATION_SUPPORT_TCPIP         9.7.0.6          6   Communication support - TCP/IP
REPL_CLIENT                         9.7.0.6          6   Replication tools
DB2_DATA_SOURCE_SUPPORT             9.7.0.6          6   DB2 data source support
LDAP_EXPLOITATION                   9.7.0.6          6   DB2 LDAP support
INSTANCE_SETUP_SUPPORT              9.7.0.6          6   DB2 Instance Setup wizard
SPATIAL_EXTENDER_CLIENT_SUPPORT     9.7.0.6          6   Spatial Extender client
APPLICATION_DEVELOPMENT_TOOLS       9.7.0.6          6   Base application development tools

As we identified the problem now we shall install the Informix Data source support, i'm using response file installation for this as its a single component installation. Just copy below things and change the parameter "FILE" according to your already installed location of db2 server

PROD                        = ADVANCED_ENTERPRISE_SERVER_EDITION
FILE                        = /opt/ibm/db2/V9.7_01
LIC_AGREEMENT               = ACCEPT
INSTALL_TYPE                = CUSTOM  
COMP                        = INFORMIX_DATA_SOURCE_SUPPORT

I will save above 5 lines in /home/db2inst1/resp

Now i will install the single component informix_data_source_support using below command

db2inst1@test-machine:~/server$ sudo ./db2setup -r /home/db2inst1/resp 
WARNING:
DBT3534W  The db2prereqcheck utility determined that ASLR is set to ON and that this could cause issues with some tools.
WARNING:
   The 32-bit library file libpam.so is not found on the system.
DBI1191I  db2setup is installing and configuring DB2 according to the
      response file provided. Please wait.

A minor error occurred while installing "DB2 Advanced Enterprise Server
Edition " on this computer. Some features may not function correctly.
For more information see the DB2 installation log at "/tmp/db2setup.log".

Once done i have connected to database and was able to create wrapper successfully

db2inst1@test-machine:/opt/ibm/db2/V9.7_01/instance$ db2 connect to attempt

   Database Connection Information

 Database server        = DB2/LINUXX8664 9.7.6
 SQL authorization ID   = DB2INST1
 Local database alias   = ATTEMPT

db2inst1@test-machine:/opt/ibm/db2/V9.7_01/instance$ db2 create wrapper drda
DB20000I  The SQL command completed successfully.

Sunday, June 8, 2014

Changing the data type of a column in replicated table in DB2 Q Replication

db2inst1@sairam:~$ db2 describe table task

                                Data type                     Column
Column name                     schema    Data type name      Length     Scale Nulls
------------------------------- --------- ------------------- ---------- ----- ------
TASK_ID                         SYSIBM    INTEGER                      4     0 No    
TASK_INFO                       SYSIBM    VARCHAR                     10     0 Yes   
SALARY                          SYSIBM    VARCHAR                     10     0 Yes   

  3 record(s) selected.

We want to change SALARY column datatype from varchar(10) to char(20) 

Steps to change the data type:

1) Stop the subscription by passing capstop signal
2) stop the data capture changes to none on both databases
3) alter the column with the new data type on both sides
4) start the data capture changes to yes on both databaes
5) Start the subscription by passing capstart signal

1) db2inst1@sairam:~$ db2 connect to testb

   Database Connection Information

 Database server        = DB2/LINUXX8664 9.7.9
 SQL authorization ID   = DB2INST1
 Local database alias   = TESTB

db2inst1@sairam:~$ db2 "insert into ASNTB.IBMQREP_SIGNAL (SIGNAL_TIME,SIGNAL_TYPE,SIGNAL_SUBTYPE,SIGNAL_INPUT_IN) values (CURRENT TIMESTAMP,'CMD','CAPSTOP','TASK0002')"
DB20000I  The SQL command completed successfully.

2) db2inst1@sairam:~$ db2 alter table task data capture none      - ( on both databases )
DB20000I  The SQL command completed successfully.

3) db2inst1@sairam:~$ db2 "alter table task alter column task_info set data type char(20)"     - ( on both databases )
DB20000I  The SQL command completed successfully.

4) db2inst1@sairam:~$ db2 alter table task data capture changes
DB20000I  The SQL command completed successfully.

5) db2inst1@sairam:~$ db2 "insert into ASNTA.IBMQREP_SIGNAL (SIGNAL_TIME,SIGNAL_TYPE,SIGNAL_SUBTYPE,SIGNAL_INPUT_IN) values (CURRENT TIMESTAMP,'CMD','CAPSTART','TASK0001')"   - ( on one side )
DB20000I  The SQL command completed successfully.

Resolving conflicts due to particular sqlstate in DB2 Q Replication

I had a situation when i tried to insert a row in source which was detected as conflict at target so Q Apply program stopped processing, so now if we want that transaction to be ignored we need to tell q apply program to ignore it .

2014-06-08-12.47.57.547884 ASN0552E  "Q Apply" : "ASNTA" : "BR00000AG012" : The program encountered an SQL error. The server name is "". The SQL request is "EXEC". The table name is "run SQL". The SQLCODE is "-668". The SQLSTATE is "57016". The SQLERRMC is "". The SQLERRP is "SQLDTBLR".
2014-06-08-12.52.03.789464 <brwzMain> ASN7524E  "Q Apply" : "ASNTA" : "BR00000" : The Q Apply program encountered an error or conflict for Q subscription  "STAFF0002" (receive queue  "ASNTB.TESTB_TO_ASNTA.TESTA.DATA", replication queue map "TESTB.ASNTB_TO_TESTA.ASNTA"). It stopped reading from the receive queue. The error occurred while applying a row from the transaction corresponding to the LSN "0000:0000:0000:04d6:82d3".

Below are steps the pass to ibmqrep_targets to ignore that transaction for particular sql state.

db2inst1@sairam:~$ db2 connect to testa

   Database Connection Information

 Database server        = DB2/LINUXX8664 9.7.9
 SQL authorization ID   = DB2INST1
 Local database alias   = TESTA

db2inst1@sairam:~$ db2 "update asnta.ibmqrep_targets set oksqlstates='57016' where subname='STAFF0002'"
DB20000I  The SQL command completed successfully.

Then it had successfully ignored that transaction alone and q apply started processing the Receive queue.

Resetting Q subscriptions that are in inconsistent states in DB2 Q Replication

Q subscriptions are considered to have inconsistent states when the state (active, inactive, new) is different between the source and target servers. In such cases we can't activate the subscriptions without bringing them into same state(inactive, new). I was able to propagate a situation where there is a table "STAFF" for which the state between source and targets was different. 

Below are the subnames and their state from both databases we can observe the state as G for subname STAFF0001 in TESTA database, where as state as I for subname STAFF0002 in TESTB database 

db2inst1@sairam:~$ db2 connect to testa

   Database Connection Information

 Database server        = DB2/LINUXX8664 9.7.9
 SQL authorization ID   = DB2INST1
 Local database alias   = TESTA

db2inst1@sairam:~$ db2 "select subname,state from asnta.ibmqrep_subs"

SUBNAME                                                                                                                              STATE
------------------------------------------------------------------------------------------------------------------------------------ -----
DBA0001                                                                                                                              A    
STAFF0001                                                                                                                            G    

  2 record(s) selected.

db2inst1@sairam:~$ db2 connect to testb

   Database Connection Information

 Database server        = DB2/LINUXX8664 9.7.9
 SQL authorization ID   = DB2INST1
 Local database alias   = TESTB

db2inst1@sairam:~$ db2 "select subname,state from asntb.ibmqrep_subs"

SUBNAME                                                                                                                              STATE
------------------------------------------------------------------------------------------------------------------------------------ -----
DBA0002                                                                                                                              A    
STAFF0002                                                                                                                            I    

  2 record(s) selected.
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Steps to reset the incosistent states in Q Replication

1) Stop capture and apply processes this is important before you update the state of subs and targets


2) UPDATE ASNTA.IBMQREP_SUBS SET STATE='I', STATE_TRANSITION=NULL WHERE SUBNAME='STAFF0001';

UPDATE ASNTA.IBMQREP_TARGETS SET STATE='I' WHERE SUBNAME='STAFF0002';

3) Start the capture and apply process now. We have state as INACTIVE in both sides so lets activate the subscription in the next step


4) INSERT INTO ASNTA.IBMQREP_SIGNAL (SIGNAL_TYPE, SIGNAL_SUBTYPE, SIGNAL_INPUT_IN) VALUES ('CMD','CAPSTART','STAFF0001');

------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

db2inst1@sairam:~$ db2 connect to testb

   Database Connection Information

 Database server        = DB2/LINUXX8664 9.7.9
 SQL authorization ID   = DB2INST1
 Local database alias   = TESTB

db2inst1@sairam:~$ db2 "select subname,state from asntb.ibmqrep_subs"

SUBNAME                                                                                                                              STATE
------------------------------------------------------------------------------------------------------------------------------------ -----
DBA0002                                                                                                                              A  
STAFF0002                                                                                                                            A  

  2 record(s) selected.

db2inst1@sairam:~$ db2 connect to testa

   Database Connection Information

 Database server        = DB2/LINUXX8664 9.7.9
 SQL authorization ID   = DB2INST1
 Local database alias   = TESTA

db2inst1@sairam:~$ db2 "select subname,state from asnta.ibmqrep_subs"

SUBNAME                                                                                                                              STATE
------------------------------------------------------------------------------------------------------------------------------------ -----
DBA0001                                                                                                                              A  
STAFF0001                                                                                                                            A  

  2 record(s) selected.

Saturday, May 17, 2014

Using ASNTDIFF and ASNTREP utilities to sync the data between source and target tables in DB2 Q replication

When you observe that there are some data differences between source and target tables in DB2 Q replication, we can use these 2 utilities( asntdiff, asntrep ) which can compare the source and target and repair them based on our requirement to synchronize the data.



ASNTDIFF : asntdiff utility which can compare two relational tables and generate a list of differences between the two.

ASNTREP  : asntrep utility will syncronize a source and target table by repairing differences between the two tables.

Important note : Its always good to synchronize the tables when there is less amount of activity or no activity going at source so that we can have perfectly synchronized table.    

Below tutorial demonstrates the use of asntdiff to compare the source and target and asntrep to repair the target table based on differences generated by asntdiff. Below is the data populated on source and target without replication enabled. Then i have created the subscription for the table AUCTION with target having no load option so that it wont try to reload the data using source as we are in process syncing the tables

1) In this first step i have created a table with same definition in source and target and loaded data with some differences in both of them

db2inst1@murali:~$ db2 connect to testa

   Database Connection Information

 Database server        = DB2/LINUXX8664 9.7.9
 SQL authorization ID   = DB2INST1
 Local database alias   = TESTA

db2inst1@murali:~$ db2 "select * from auction"

ITEMID     CATEGORY   PRICE    
---------- ---------- -----------
A0001      HOME                54
A0002      GENERAL             17
A0003      SPARES             120
A0004      GENERAL             32
A0006      GENERAL             40

  5 record(s) selected.

db2inst1@murali:~$ db2 connect to testb

   Database Connection Information

 Database server        = DB2/LINUXX8664 9.7.9
 SQL authorization ID   = DB2INST1
 Local database alias   = TESTB

db2inst1@murali:~$ db2 "select * from auction"

ITEMID     CATEGORY   PRICE    
---------- ---------- -----------
A0001      HOME                15
A0002      HOME                12
A0003      HOME                35
A0006      HOME                50

  4 record(s) selected.

2) I'm here considering TESTA as source database/correct data and TESTB is having wrong data which i want to synchronize. Let us run the asntdiff utility to find the differences between the source and target tables. As showing below in the ending line we can see that it has given us the number of differences found between the source and target table: "5". These details can be found in database "TESTA", and it has stored the diff values in the difference table DIFFSCHEMA1.DIFF_AUCTION

db2inst1@murali:~$ asntdiff DB=TESTA SCHEMA=ASNTA DIFF_SCHEMA=DIFFSCHEMA1 DIFF=DIFF_AUCTION  where="SUBNAME = 'AUCTION0001'"

2014-05-17-17.12.21.904722 ASN0600I  "AsnTDiff" : "" : "Initial" : Program "asntdiff 9.7.9" is starting.
2014-05-17-17.12.22.005751 ASN4012I  "AsnTDiff" : "ASNTA" : "Initial" : The program is comparing tables using the list of parameters following this message.
 TDIFF   TABLE = "DIFFSCHEMA1"."DIFF_AUCTION" ;
 MAXIMUM COUNT = 100000 ;

  CONNECT TO TESTA ;

  SELECT "CATEGORY" AS "CATEGORY",    "PRICE" AS "PRICE",    "ITEMID" AS "ITEMID" FROM "DB2INST1"."AUCTION"  ORDER BY 3 ;

  CONNECT TO TESTB ;

  SELECT "CATEGORY",    "PRICE",    "ITEMID" FROM "DB2INST1"."AUCTION"  ORDER BY 3 ;

  CREATE TABLE "DIFFSCHEMA1"."DIFF_AUCTION" (
    "DIFF "         CHAR(4),
    "ITEMID"           VARCHAR(10)
  ) ;

2014-05-17-17.12.22.416439 ASN4006I  "AsnTDiff" : "ASNTA" : "Initial" : Between the source table and the target table, there are "0" common rows, "5" rows that are unique to the source table, and "4" rows that are unique to the target table.
2014-05-17-17.12.22.438578 ASN4010I  "AsnTDiff" : "ASNTA" : "Initial" : Number of differences found between the source and target table: "5". The details can be found in database "TESTA", difference table ""DIFFSCHEMA1"."DIFF_AUCTION"".
----------------------------------------------------------------------

3) Let us see what differences it has identified between source and target and have stored in the difference table. As show below we can see it contains 4 UPDATES and 1 INSERT

db2inst1@murali:~$ db2 "select * from "DIFFSCHEMA1"."DIFF_AUCTION""

DIFF  ITEMID  
----- ----------
U  2  A0001  
U  2  A0002  
U  2  A0003  
U  2  A0006  
I  2  A0004  

  5 record(s) selected.

4) Now to repair the table at target we are running asntrep using the same difference table, that was created in earlier step. So it should perform 4 updates and 1 insert in target side. As shown in the ending line we can see The program applied the rows from the difference table to the target table as follows: "1" rows were inserted, "4" rows were updated, and "0" rows were deleted.

db2inst1@murali:~$ asntrep DB=TESTA SCHEMA=ASNTA DIFF_SCHEMA=DIFFSCHEMA1 DIFF=DIFF_AUCTION WHERE="SUBNAME = 'AUCTION0001'"

2014-05-17-17.13.49.984558 ASN0600I  "AsnTRep" : "" : "Initial" : Program "asntrep 9.7.9" is starting.

CREATE TABLE "DIFFSCHEMA1"."DIFF_AUCTION-" (
    "DIFF "            CHAR(4),
    "ITEMID"           VARCHAR(10)
)  ;

DELETE
FROM   "DB2INST1"."AUCTION" T
WHERE  EXISTS (

   SELECT 1 FROM "DIFFSCHEMA1"."DIFF_AUCTION-" D

   WHERE  ( T."ITEMID" = D."ITEMID"  OR
            T."ITEMID" IS NULL AND D."ITEMID" IS NULL )
   AND      D."DIFF " LIKE 'D%' ) ;



INSERT INTO "DB2INST1"."AUCTION" (
   "CATEGORY",
   "PRICE",
   "ITEMID" ) VALUES(  ?,  ?,  ? ) ;


SELECT T.*
FROM ( SELECT "CATEGORY" AS "CATEGORY",
   "PRICE" AS "PRICE",
   "ITEMID" AS "ITEMID" FROM "DB2INST1"."AUCTION"
) AS T

WHERE EXISTS ( SELECT 1 FROM "DIFFSCHEMA1"."DIFF_AUCTION" AS D
   WHERE  ( T."ITEMID" = D."ITEMID"  OR
            T."ITEMID" IS NULL AND D."ITEMID" IS NULL )
   AND      D."DIFF " LIKE 'I%' ) FOR READ ONLY ;

UPDATE "DB2INST1"."AUCTION"
SET
 "CATEGORY" = ?,
 "PRICE" = ?
WHERE
 "ITEMID" = ?

   SELECT T.*  FROM ( SELECT "CATEGORY" AS "CATEGORY",    "PRICE" AS "PRICE",    "ITEMID" AS "ITEMID" FROM "DB2INST1"."AUCTION"  ) AS T    WHERE EXISTS ( SELECT 1 FROM "DIFFSCHEMA1"."DIFF_AUCTION" AS D     WHERE  ( T."ITEMID" = D."ITEMID"  OR             T."ITEMID" IS NULL AND D."ITEMID" IS NULL )    AND      D."DIFF " LIKE 'U%' ) FOR READ ONLY ;

2014-05-17-17.13.50.321421 ASN4019I  "AsnTRep" : "ASNTA" : "Initial" : The program applied the rows from the difference table to the target table as follows: "1" rows were inserted, "4" rows were updated, and "0" rows were deleted.
----------------------------------------------------------------------

5) Now lets check the data in target to see if it really worked.

db2inst1@murali:~$ db2 connect to testb

   Database Connection Information

 Database server        = DB2/LINUXX8664 9.7.9
 SQL authorization ID   = DB2INST1
 Local database alias   = TESTB

db2inst1@murali:~$ db2 "select * from auction"

ITEMID     CATEGORY   PRICE    
---------- ---------- -----------
A0001      HOME                54
A0002      GENERAL             17
A0003      SPARES             120
A0006      GENERAL             40
A0004      GENERAL             32

  5 record(s) selected.

NOTE:

From my experience when we need to synchronize big tables we need to specify the conditions on which asntdiff and asntrep should run, else it might take a lot of time to find the differences between source and target, also sometimes it also fails. Its always important to understand the business logic and use these utilities with utmost care to make sure we moving in right direction.

Adding a new column to replicated table in DB2 Q Replication

This tutorial will help you understand on how to add a new column to table which is already replicated, This tutorial applies for Q Replication with bidirectional setup ( active - active solution ) that i was using in my earlier posts. Description of table is below to which we shall add one new column, name it as ADDRESS VARCHAR(10)

db2inst1@murali:~$ db2 describe table dba

                                Data type                     Column
Column name                     schema    Data type name      Length     Scale Nulls
------------------------------- --------- ------------------- ---------- ----- ------
NAME                            SYSIBM    VARCHAR                     10     0 Yes
ID                              SYSIBM    INTEGER                      4     0 No  

  2 record(s) selected.


Basic steps are like this

1) Check the subscription of the table on source and target and see if it active before we add a new column
2) Add the column with normal alter table add column command to the source table
3) Pass the signal to replication so it can understand that we have added a new column to table
4) Check on the target side if the column is added or not

1)

db2inst1@murali:~$ db2 connect to testa

   Database Connection Information

 Database server        = DB2/LINUXX8664 9.7.9
 SQL authorization ID   = DB2INST1
 Local database alias   = TESTA

db2inst1@murali:~$ db2 "select subname,state from asnta.ibmqrep_subs where source_name='DBA'"

SUBNAME                                                                                                                              STATE
------------------------------------------------------------------------------------------------------------------------------------ -----
DBA0001                                                                                                                              A  

  1 record(s) selected.

db2inst1@murali:~$ db2 connect to testb

   Database Connection Information

 Database server        = DB2/LINUXX8664 9.7.9
 SQL authorization ID   = DB2INST1
 Local database alias   = TESTB

db2inst1@murali:~$ db2 "select subname,state from asntb.ibmqrep_subs where source_name='DBA'"

SUBNAME                                                                                                                              STATE
------------------------------------------------------------------------------------------------------------------------------------ -----
DBA0002                                                                                                                              A  

  1 record(s) selected.


2)

db2inst1@murali:~$ db2 "alter table dba add column address varchar(10)"
DB20000I  The SQL command completed successfully.

3)

db2inst1@murali:~$ db2 "insert into ASNTA.IBMQREP_SIGNAL(SIGNAL_TIME,SIGNAL_TYPE,SIGNAL_SUBTYPE,SIGNAL_INPUT_IN,SIGNAL_STATE) values ( CURRENT TIMESTAMP,'CMD','ADDCOL','DBA0001;ADDRESS','P' )"
DB20000I  The SQL command completed successfully.

4)

db2inst1@murali:~$ db2 connect to testb

   Database Connection Information

 Database server        = DB2/LINUXX8664 9.7.9
 SQL authorization ID   = DB2INST1
 Local database alias   = TESTB

db2inst1@murali:~$ db2 describe table dba

                                Data type                     Column
Column name                     schema    Data type name      Length     Scale Nulls
------------------------------- --------- ------------------- ---------- ----- ------
NAME                            SYSIBM    VARCHAR                     10     0 Yes
ID                              SYSIBM    INTEGER                      4     0 No  
ADDRESS                         SYSIBM    VARCHAR                     10     0 Yes

  3 record(s) selected.

All the commands used in this post are highlighted in ITALIC

Wednesday, May 14, 2014

Learning DB2 Basics

Its always good to learn basics so let me share you some best books and tutorials.

1) Learning db2 visually with examples 2nd edition 2008 - this is my favorite book for DB2 learners . I got a soft copy luckily somewhere in internet, Often i read it on GS3 when i get bored ..



Link to download : https://www.mediafire.com/?cuy2zr07roj3et1  ( please don't share any alternative links as i want to see the original downloads count )

2) Want to learn db2 in video tutorials, luckily we have one for that as well. We can even download offline copy to watch it. You have to signup using Google or some... Its has two parts of tutorials. Once you read everything you can also take test to evaluate your learning's.

1) DB2 Essential Training I  (DB101EN)
2) DB2 Essential Training II (DB102EN)





Tuesday, May 13, 2014

Automatically reroute your client requests in DB2 HADR in the event of failure

You can use automatic client reroute (ACR) with high availability disaster recovery (HADR) to transfer client application requests from a failed database server to a standby database server.

Today i will show how to implement it practically and see how it works. I'm using the same setup that i have did in my earlier post on how to setup DB2 HADR, so refer to that and setup in your environment.


Basic steps are like these.

1) Setup HADR pair and see that they are in peer mode.
2) UPDATE ALTERNATIVE SERVER configuration on the primary and standby database.
3) Catalog the primary database at the standby node/instance
4) takeover the hadr on standby database
5) run the query to test it and see if we are connected to standby from client


1) Setup HADR and check if HADR pair is in peer state or not

db2pd -db char -hadr


2)
on primary:
db2 update alternate server for database char using hostname sairam port 65000

on standby:
db2 update alternate server for database char using hostname sairam port 64000

3)
on standby:

db2 catalog tcpip node primeno remote sairam server 64000
db2 catalog database char as apple at node primeno

from standby instance connect to primary database which is cataloged as local database

db2inst2@sairam:~$ db2 connect to apple user db2inst1
Enter current password for db2inst1:

   Database Connection Information

 Database server        = DB2/LINUXX8664 9.7.9
 SQL authorization ID   = DB2INST1
 Local database alias   = APPLE

db2inst2@sairam:~$ db2 "select * from  tab1"

COL1    
-----------
          1
          2
          3

  3 record(s) selected.

Note : Dont close this session as we need to check the same query from same session as described in step 5

4)

on standy: use a different session to give this command

Issue a takeover on the standby database to switch the HADR role

db2inst2@sairam:~$ db2 takeover hadr on database char
DB20000I  The TAKEOVER HADR ON DATABASE command completed successfully.

5)

from the same session from step 3 - Issue the same select query again, It will display us the warning message as connection to old database has been lost and trying to connect to new primary database. As show below If you give select query with out ur isolation level it throws error because we are connected to standby database and we need to maintain UR isolation level.

db2inst2@sairam:~$ db2 "select * from  tab1"
SQL30108N  A connection failed but has been re-established. Special register
settings might have been replayed. Host name or IP address of the new
connection: "sairam". Service name or port number of the new connection:
"64000".  Reason code: "1".  SQLSTATE=08506

db2inst2@sairam:~$ db2 "select * from  tab1"

COL1    
-----------
SQL1773N  The statement or command requires functionality that is not
supported on a read-enabled HADR standby database. Reason code = "1".

db2inst2@sairam:~$ db2 "select * from  tab1 with ur"

COL1    
-----------
          1
          2
          3

  3 record(s) selected.

All commands that i used in this post are highlighted in ITALIC 

Friday, May 9, 2014

8 steps to setup DB2 HADR solution

High Availability disaster Recovery solution HADR in DB2 is one of robust ways of maintaining two db2 databases in SYNC for high availability solutions.

We can use primary database for read,write operations and standby database for read operations or completely for disaster solution in case if primary fails.
Setting up HADR in DB2 is one of the easiest one that i ever worked, it took me only half hour to setup and test the solution.

Basic step are like these.
create a database on one machine/instance
set HADR DB parameters on primary database
backup database on primary
restore the image in standby machine/instance
set HADR DB parameters on standby database
start hadr on standby first then on primary database
Validate the HADR setup

Here is how my setup look like




1) db2 create database samsung

2) db2 update db cfg for samsung using logarchmeth1 DISK:/home/db2inst1/logs

3) Setting up HADR cfg parameters on primary database

update db cfg for samsung using HADR_LOCAL_HOST sairam
update db cfg for samsung using HADR_LOCAL_SVC 64000
update db cfg for samsung using HADR_REMOTE_HOST sairam
update db cfg for samsung using HADR_REMOTE_SVC 65000
update db cfg for samsung using HADR_REMOTE_INST db2inst2
update db cfg for samsung using LOGINDEXBUILD ON

4) Take an offline backup to be used for setting HADR, move the backup image (from the primary machine/instance) to the standby machine/instance

5) restore the database on standby instance

db2 restore db samsung taken at 20140509113342 on /home/db2inst2/ into apple

6) Setting up HADR cfg parameters on standby database

update db cfg for apple using HADR_LOCAL_HOST sairam
update db cfg for apple using HADR_LOCAL_SVC 65000
update db cfg for apple using HADR_REMOTE_HOST sairam
update db cfg for apple using HADR_REMOTE_SVC 64000
update db cfg for apple using HADR_REMOTE_INST db2inst1

7) Starting up HADR on the standby server

db2 start hadr on database apple as standby

8) Starting up HADR on the primary server

db2 start hadr on database samsung as primary

Finally validating the HADR setup is important.

create a table and populate some 5 rows at primary site, switch the between the roles and check if the table available in standby database.

Monday, April 28, 2014

Installing DB2 fixpack

Install DB2 Fix packs – Below steps are intended for Linux, Unix operating systems.


1) Perform the necessary tasks before installing a fix pack.
2) Choose a fix pack installation method and install the fix pack.
3) Perform the necessary tasks after installing the fix pack.
4) Apply the appropriate DB2 database product license.

1) Perform the necessary tasks before installing a fix pack

a) If you already have DB2 database product installed, the space required to install the fix pack is slightly greater than the space consumed by the existing DB2 database products. This space is only required temporarily during the fix pack installation process.

To determine the space used by the existing DB2 database products, perform the command:

du -h -s DB2DIR

where DB2DIR represents the location where the DB2 copy is installed.

b) Download the fix pack

c) Uncompress the fixpacks, use the below command

gunzip -c filename.tar.gz | tar -xvf - 

d) Before installing a fix pack, if there are DB2 database products installed in the selected installation path, you must stop all of the DB2 processes. If you have multiple DB2 copies, stop only the DB2 processes that are associated with the copy that you are updating.
Determine which instances are associated with the DB2 copy.

Issue the command: DB2DIR/instance/db2ilist

where DB2DIR represents the location where the DB2 copy is installed.

su - iname
db2 force application all
db2 terminate
db2stop
exit

If the DB2 Administration Server (DAS) belongs to the DB2 copy that you are updating, stop the DAS:
su - aname
db2admin stop
exit

where aname represents the DAS owner name.

e) Optional: On AIX, run slibclean to unload unused shared libraries from memory before installation:

/usr/sbin/slibclean

f) Disable the fault monitor processes. To stop the Fault Monitor Daemon, issue the command:

DB2DIR/bin/db2fm -i iname -D

where DB2DIR is the location where the DB2 copy is installed and iname represents the instance owner name. The command must be performed once for each instance in the DB2 copy.

g) Ensure all DB2 interprocess communications are cleaned for the instance to be updated. As the instance owner, run the following command at each physical partition:

$HOME/sqllib/bin/ipclean

2) Choose a fix pack installation method and install the fix pack.

There are 2 ways that you use the fixpack and installation methods that match the purpose.

1) Follow these instructions to install new DB2 database products at a particular fix pack level. The db2setup command is used to perform the installation.

Change to the directory that contains the fix pack image.

Launch the installation by issuing the command: ./db2setup

2) Follow these instructions if a DB2 database product is already installed and you want to apply a new fix pack level. The installFixPack command is used to install the fix pack.

You have two choices when it comes to fix pack installation; using a universal fix pack (all products) or a product-specific fix pack.

Why would I use the universal fix pack?
If I want to upgrade multiple products in place.
If I do not remember what I have installed to be able to install the fix pack in a new location without losing my current set of features or products.

Why would I use the product-specific fix pack?
If I have a single product and want to save the time to download the fix pack.
If system downtime is costly.
If I need to test the new fix pack without impacting my production databases.
If I need the ability to go back to the previous version quickly (system downtime in case of failure).
If I already have a fix pack installed and need to add new features or products to the fix pack.
Note: Many of these advantages can be achieved by installing from your original media to a new location and using the universal fix pack to upgrade features or products, however, there is a cost of extra installation time.

Launch the installation by issuing the installFixPack command. For example,

./installFixPack -b DB2DIR

where DB2DIR is the location of the DB2 database products that you want to update.

Note: I had seen below error in Linux environment.

Stopping DB2 Fault Monitor :.......Success
ERROR: The installFixPack command detected some DB2 libraries are still loaded
in memory and some applications might still be running in the current
installation copy.  All applications must be stopped. See the fix pack readme
for pre-installation instructions, and re-run the installFixPack command.
Alternatively, to override automatic checking, you can re-issue the
installFixPack command with the '-f db2lib' parameter. Note: If you re-issue
the installFixPack command with the '-f db2lib' parameter, after the DB2
instances are updated, some applications might not work properly and might need
to be restarted to function properly against the updated DB2 instance.

Preparing the system :.......Failure
Change to the directory that contains the fix pack image.

If you get error as above use the below command, and complete the install.

./installFixPack -b DB2DIR –f db2lib

3) Perform the necessary tasks after installing the fix pack.

a) For each instance, issue the command:

DB2DIR/instance/db2iupdt iname

where iname represents the instance name and DB2DIR represents the location where the DB2 copy is installed.

b) If the DB2 Administration Server (DAS) belongs to the DB2 copy where you installed the fix pack, issue the command:

DB2DIR/instance/dasupdt

where DB2DIR is the location where the DB2 copy is installed. If this DB2 copy is now running at a more recent fix pack level than all of the other DB2 copies, consider updating the DAS to belong to this DB2 copy.

c) Update the system catalog objects in your databases to support the fix pack.

db2updv97 -d dbname
where dbname represents the name of the database.

Note: Backup your database before running db2updv97. Some system objects might become unusable after moving back to an earlier fix pack, and your database will need to be restored.

d) Restart the instance , DAS admin

su - iname
db2start

su - dasuser
db2admin start

e) As part of a fix pack installation on the server, binding of the database utilities (IMPORT, EXPORT, REORG, the Command Line Processor) and the CLI bind files occurs automatically. However, if you install a fix pack on the client or an error occurs, you can manually bind the database utilities and the CLI bind files.

If you installed the fix pack on DB2 database products that have existing databases, perform the following commands once for each database:

db2 terminate
db2 CONNECT TO dbname user USERID using PASSWORD
db2 BIND path\db2schema.bnd BLOCKING ALL GRANT PUBLIC SQLERROR CONTINUE 
db2 BIND path\@db2ubind.lst BLOCKING ALL GRANT PUBLIC ACTION ADD 
db2 BIND path\@db2cli.lst BLOCKING ALL GRANT PUBLIC ACTION ADD 
db2 terminate

If you installed the fix pack on DB2 database products that have existing databases, rebind the packages by running the REBIND or db2rbind command.

db2rbind dbname -l  fullpath/logfile all 
fullpath refers to a valid path given with a name to log the rebind output

4) Apply the appropriate DB2 database product license.

INSTHOME/sqllib/adm/db2licm -a filename

Where INSTHOME represents the home directory of the instance owner and filename is the full path name and file name for the license file
Check the license information once after applying the license.

db2licm -l

All the commands used in the post are highlighted as Italic