Wednesday, 30 October 2024

How to know when your DB2 instance was started for the last time

How to know when your DB2 instance was started for the last time

Discovering when was the last time your DB2 instance was started
If you need information about the last time your DB2 instance was started, you can perform the following command:
db2 get snapshot for dbm | grep -i manager

The output result you'll get should be something like this:
Start Database Manager timestamp               = 03/17/2008 07:00:41.018041


In addiction, if you also want to know when was the last time your server was rebooted, you can perform on AIX command prompt:
$ who -b

The output for this command should be something like:
   .        system boot Jan 27 04:19

Tuesday, 29 October 2024

Dropping all tables from a specific schema

Dropping all tables from a specific schema

Use this query to select and drop all tables of a schema

SCHEMA NAME = TEST
db2 -x "select 'drop table '||rtrim(tabschema)||'.'||rtrim(tabname) from syscat.tables where tabschema = 'TEST'"

Displaying the contents of a bind file using the db2bfd tool

Displaying the contents of a bind file using the db2bfd tool


There are times when it is beneficial to examine the contents of a DB2 bind file.
For example, a vendor might supply an executable and bind file and you might want to see what kinds of SQL statements the application might execute. Also, consider the case where an errant application is deleting data from a table that is supposed to remain read-only but you aren’t sure which application is responsible. 

By examining the bind files for all of the applications that run against the database, you might be able to find a DELETE statement against the table in question and from there dig further into the application’s logic to determine what is going wrong.

The db2bfd tool can be used to display these kinds of thing as well as some other
information.
Execute the tool without any parameters to see its usage.
C:\>db2bfd
Usage: db2bfd [ [-b] [-h] [-s] [-v] ] <filespec>
Where: <filespec> is a V7 or V8 bind file

Options:
-b = display bind file header
-h = display this information
-s = display SQL statements
-v = display host variable declarations
Example 1: Use db2bfd -s to see the SQL statements contained in the db2sampl.bnd file
On Windows operating systems:
db2bfd -s %DB2PATH%\bnd\db2sampl.bnd
(where %DB2PATH% is a variable that determines where DB2® is installed)
On UNIX:
db2bfd -s $HOME/sqllib/bnd/db2sampl.bnd
(where $HOME is the home directory of the instance owner)
Next, use the -v option to see the corresponding host variables that would have been defined in the source code for db2sampl:
On Windows operating systems:
db2bfd -v %DB2PATH%\bnd\db2sampl.bnd
(where %DB2PATH% is a variable that determines where DB2® is installed)
On UNIX:
db2bfd -v $HOME/sqllib/bnd/db2sampl.bnd
(where $HOME is the home directory of the instance owner)

db2dart - How to check if a database is corrupted

db2dart - How to check if a database is corrupted

The db2dart and inspect tools can be used in database crash situations


db2dart tool


    db2dart is a command which can be used to verify the architectural correctness of
databases and the objects within them. It can also be used to display the contents
of database control files in order to extract data from tables that might otherwise
be inaccessible.
    To display all of the possible options, simply execute the db2dart utility without
any parameters. Some options that require parameters, such as the table space ID,
are prompted for if they are not explicitly specified on the command line.
    By default, db2dart will create a report file with the name databaseName.RPT. For
single-partition database environments, the file is created in the current directory.
For multiple-partition database environments, the file is created under a
subdirectory in the diagnostic directory. The subdirectory is called DART####, where
#### is the partition number.
    db2dart accesses the data and metadata in a database by reading them directly
from disk. Because of that, db2dart should never be run against a database that
still has active connections
. If there are connections, db2dart will not know about
pages in the buffer pool, control structures in memory, etc. and may report false
errors as a result. Similarly, if you run db2dart against a database that requires
crash recovery or that has not completed roll-forward recovery, similar
inconsistencies might result due to the inconsistent nature of the data on disk.
Inspecting databases, table spaces, and tables via db2dart:

    The default behavior for db2dart is to inspect the entire database. Only the
database name must be provided in this case. For example:
C:\>db2dart sample
The requested DB2DART processing has completed successfully!
Complete DB2DART report found in:
C:\IBM\SQLLIB\DB2\DART0000\SAMPLE.RPT
    As the output states, the full db2dart report can be found in the file SAMPLE.RPT.
You will also notice that in this case db2dart did not find any problems with the
database.
    If a database is very large and you are only interested in one table space, you can
use the /TS option. When using this option, you must either provide the table
space ID on the command line (by specifying the /TSI parameter) or you can let
db2dart prompt you for it. If you do not know the table space ID, you can obtain
it via the command DB2 LIST TABLESPACES command. For example, to inspect the
USERSPACE1 table space (which has a table space ID of 2 in the sample database),
either of these commands will work:
db2dart sample /ts /tsi 2

            or

db2dart sample /ts <= When prompted for the table space ID, enter "2".

    Similarly, a single table and its associated objects (LOBs, indexes, etc.) can be
inspected using the /T option. When using this option, you must provide either the
table name or object ID and the ID of the table space in which the table resides. To
determine the object ID and table space ID for a table, you can query the FID and
TID columns of the SYSIBM.SYSTABLES catalog table. For example, determine the
object ID and table space ID for the EMP_PHOTO table in the sample database by
executing the following query:
C:\>db2 connect to sample
Database server = DB2/NT 8.2.0
SQL authorization ID = LISAC
Local database alias = SAMPLE
C:\>db2 "select creator,name,tid,fid from sysibm.systables where name =
’EMP_PHOTO’"

CREATOR NAME TID FID
------------------ --------------------- ------ ------
DB2 EMP_PHOTO 2 8
1 record(s) selected.

C:\>db2 connect reset
DB20000I The SQL command completed successfully.

To inspect this table, execute either of the following db2dart commands:
db2dart sample /t /tsi 2 /oi 8
db2dart sample /t <= When prompted for the table ID and table space ID, 
enter "8 2".
As mentioned above, the table name can be specified instead of the object ID:
db2dart sample /t /tsi 2 /tn EMP_PHOTO
db2dart sample /t <= When prompted for the table name and table space ID,
enter "EMP_PHOTO 2".
Dumping formatted table data via db2dart:
If a table space or table becomes corrupt for any reason (for example due to a bad
disk or disk controller), attempts to access the table through SQL may not work.
(The SQL statement may fail with an error or the database may be marked bad
and all connections will be dropped.) In such a case, entries will likely be written
to the db2diag.log file, indicating that a bad page was encountered.
2004-10-12-16.49.20.119228+120 I3292G436 LEVEL: Error
PID : 14974 TID : 605992128 PROC : db2bm.14206.5
INSTANCE: db2inst1 NODE : 000 DB : SAMPLE
APPHDL : 0-777 APPID: *LOCAL.db2inst1.000
FUNCTION: DB2 UDB, buffer pool services, sqlbrdpg, probe:1143
RETCODE : ZRC=0x86020001=-2046689279=SQLB_BADP "page is bad"
DIA8400C A bad page was encountered.

    If you see such entries, you should run db2dart against the database (or table
space) to determine the extent of the damage.
    If this happens, it may be necessary to extract all of the data possible so that the
table space and table can be rebuilt. In such a situation, the /DDEL option of
db2dart can be used to extract the table data and place it into a delimited ASCII
file. Note that due to the nature of ASCII files, some columns (such as LOB
columns) cannot be extracted from the table. db2dart will tell you if this is the case.
    When using the /DDEL option, you must provide a table space ID, object ID,
starting page number, and number of pages. To extract all of the pages, use 0 for
the starting page number and some very large number for the number of pages.
(Specifying more pages than actually exist will not cause any problems.)
The ORG table in the sample database resides in table space 2 and has an object ID
of 2. To extract all of the data from this table, execute this command:
db2dart sample /ddel

When prompted, enter either of the following lines of input:

2 2 0 1000
ORG 2 0 1000

You will then be presented with the column definitions for the table and will be
asked to specify an output file name:
Table object data formatting start.
Please enter
Table ID or name, tablespace ID, first page, num of pages:
(suffic page number with ’p’ for pool relative)
2 2 0 1000
5 of 5 columns in the table will be dumped.
Column numbers and datatypes of the columns dumped:
0 SMALLINT
1 VARCHAR() -VARIABLE LENGTH CHARACTER STRING
2 SMALLINT
3 VARCHAR() -VARIABLE LENGTH CHARACTER STRING
4 VARCHAR() -VARIABLE LENGTH CHARACTER STRING

Default filename for output data file is TS2T2.DEL,

do you wish to change filename used? y/n

You can choose the default or specify a new one. 
The output file will be created in the current directory be default.
When the extraction is complete, you will see output as follows:
Filename used for output data file is TS2T2.DEL. 
If existing file, data will be appended to it.
Formatted data being dumped ...
Dumping Page 0 ....
Table object data formatting end.
The requested DB2DART processing has completed successfully!

db2audit - basic commands and tips

db2audit - basic commands and tips

db2audit is a tool available on DB2 that generates logging for some security events on the database, for example check authorization, security management, users validation, modifications in database objects.

db2audit commands


Here are some basic commands for db2audit:

db2audit start -> to start db2audit
db2audit stop -> to stop db2audit
db2audit describe -> to check db2audit status


db2audit describe
DB2 AUDIT SETTINGS:
Audit active: "TRUE "
Log audit events: "FAILURE"
Log checking events: "FAILURE"
Log object maintenance events: "FAILURE"
Log security maintenance events: "FAILURE"
Log system administrator events: "FAILURE"
Log validate events: "FAILURE"
Log context events: "NONE"
Return SQLCA on audit error: "FALSE "
Audit Data Path: ""
Audit Archive Path: ""
AUD0000I  Operation succeeded


db2audit tip


When installing db2audit, be careful on updating the parameter audit_buf_sz of dbm cfg:

       If you want to set an assyncrhonous logging, you should keep audit_buf_sz with zero value. In this case, all information collected by db2audit will be written directly to the disk, what may cause performance problems on the database.

        Generally, we update the parameter using the value 64 or 128 (depending on the volumn of dynamic SQL).

Monday, 28 October 2024

DB2 Lock Modes

DB2 Lock Modes

some of the locking modes used by DB2

Intent Locks (IN, IS, IX, SIX)


The intent mode locks are used at the table, block (for MDC tables) and Data Partitions (for Range based Table partitioning) locks. These are not used at the row level.

  •  The Intent None (IN) locks are used for uncommitted read applications.
   The Intent locks allow other transactions to perform reads and writes to the table,
   except for the SIX lock, which only allows others to perform reads.
  •  The Intent Share (IS) and Intent Exclusive (IX) are used at the table, block and data
   partition level, but require transactions to lock lower granular objects in the hierarchy
   when reading data. For example, an application using Cursor Stability might acquire an
   IS lock for a table and then get NS locks at the row level.
  • The Intent Exclusive (IX) and SIX locks allow transactions to update lower granular
   objects, but require additional locking at the lower levels.

Non-intent Locks


       Of the non-intent locking modes, DB2 can use NS, S and U locks for read requests. The NS locks are only used at the row level for applications using CS and RS isolation levels. Repeatable Read isolation level uses the S lock at the row level.

  • The U mode lock is used for intent to update locking. It allows deadlock prevention as it is not compatible with itself. DB2 could acquire a U lock for application 1, when a row is retrieved for a cursor with the FOR UPDATE clause. If application 2 also tries to access the same row using a cursor defined FOR UPDATE, the request for a U lock for the row will force application 2 to wait for the first application to release the lock. DB2 utilities like LOAD and REORG use table level U locks to allow concurrent read activity but prevent any concurrent updates.
  • DB2 uses the non-intent mode locks Exclusive (X), Super exclusive (Z) and Next Key Weak(NW) for write requests.
           
           1 - A Z mode lock is super-exclusive, no access by any other transaction. It is mainly used by DB2 utilities and DDL statements like ALTER TABLE, to insure operations are performed with no concurrent access.
           2 - The Exclusive, X mode locks are used for writes, but allow UR isolation level applications to process read activity concurrently.
           3 - The NW mode lock is used only to lock the next key in an index when inserting a key whenthe next key is already locked by an application scanner using the RR isolation level.

LOCK COMPATIBILITY MATRIX




INISNSSIXSIXUNWXZ
INokokokokokokokokokx
ISokokokokokokokxxx
NSokokokok xxokokxx
Sokokokok xxokxxx
IXokokxxokxxxxx
SIXokokxxxxxxxx
Uokokokokxxxxxx
NWokxokxxxxxxx
Xokxxxxxxxxx
Zxxxxxxxxxx

The table shows which lock modes are compatible with other locking modes.
This shows that an application using Uncommitted Read isolation, that needs a Intent None
(IN) table lock can acquire the lock with any of the other lock modes already held by
another application, with the exception of the Super Exclusive Z lock. An offline REORG
utility uses the Z lock at the table level when it needs to insure there are no applications
with access to the table. Notice that the table shows no lock mode is compatible with a Z
lock.

Creating backup images in DB2

Creating backup images

How to create backup images of your database, under Unix servers
To create simple backup images, perform the following command:

db2 backup database <db_name>

It will create a backup image file at the current directory the command was issued, in case of the command completes successfully. You need to havesysadm, sysctrl or sysmaint authorization to perform a backup operation.

To create an online backup image, use the following command:

db2 backup database <db_name> online to </backup_filesystem>

If you want to do a backup and the target file system is made up of multiple physical disks, perform the following command:
db2 backup database <db_name> to </backup_filesystem>, </backup_filesystem>, </backup_filesystem>

The data will be concurrently backed up to the three target directories, and three backup images will be generated with extensions .001, .002, and.003.


If you need further information about backups and backing up a database, you should visit the web-site:

http://publib.boulder.ibm.com/infocenter/db2luw/v8/index.jsp?topic=/com.ibm.db2.udb.doc/admin/c0006150.htm

Configuring DB2 and TSM in Unix / Linux

Configuring DB2 and TSM in Unix / Linux

Configuration steps required for DB2 to work with TSM on Unix/Linux.

A few notes before configuring DB2 for TSM:
  • The TSM API bit level needs to match the DB2 bit level; the bit level of the OS does not affect this. For example, if a 32bit DB2 Instances is installed on a 64bit AIX OS, then the 32bit TSM API should be installed to match the bit level of the DB2 instance.
  • Keep in mind that the db2adutl and dsmapipw utilities use the TSM API environment variables (the DSMI variables) that are set in their current working shell. Therefore, any changes to the DSMI environment variables will be seen immediately by these utilities. However, DB2 utilizes the environment variables from memory that are loaded when the instance is started. Therefore, any changes to these DSMI environment variables require the DB2 instance to be recycled (i.e. db2stop/db2start) for the changes to take affect.
  • If any of the TSM API files (such as dsmtca, libApiDS.a, or libApiTSM64.a) were copied from one TSM API install directory to another, from the TSM B/A client directory, or from one system to another, then it is suggested to uninstall the TSM API, delete the TSM API install directory, and then reinstall the TSM API to ensure that the appropriate bit level of the files exist in the correct location.

To ensure that DB2 and the TSM API are properly configured, perform the following steps:
1. Log in with DB2 Instance owner (or use "su - db2inst1") and run:
db2level
  • From this output, verify if this is a 32 or 64bit DB2 instance
  • If DB2 is 32bit, install the 32bit TSM API
  • If DB2 is 64bit, install the 64bit TSM API

set | grep DSMI
  • Determine the current setting for the TSM API environment variables
  • DSMI_DIR should specify the:
  • /<opt or usr>/tivoli/tsm/client/api/bin directory if DB2 is 32bit
  • /<opt or usr>/tivoli/tsm/client/api/bin64 directory if DB2 is 64bit
  • the dsm.sys file must exist, or have link to it, in this DSMI_DIR directory
  • DSMI_CONFIG should specify a full path and file name for TSM user options file (i.e., dsm.opt)
  • verify that "servername xyz" in this dsm.opt corresponds to an existing "servername xyz" stanza in the $DSMI_DIR/dsm.sys
  • DSMI_LOG, if defined, should specify a directory that is read/writable by DB2
Note that the errorlogname parameter takes precedence over the DSMI_LOG variable.
  • if errorlogname exists in the stanza in the dsm.sys ensure the file specified has RW access by the db2 user

2. Edit the file $HOME/sqllib/userprofile to include the DSMI variables from above
  • As of DB2 8.2 (DB2 8.1 fixpack 7), DB2 will only use the DSMI variables defined in this $HOME/sqllib/userprofile.
  • Defining these DSMI variables solely in the $HOME/.profile is no longer sufficient as they will be ignored by DB2.

3. At the bottom of the $HOME/.profile (for Korn shell) or $HOME/.bash_profile (for Bash shell) or the equivalent for any other shell, source (i.e. execute/run) the DB2 file $HOME/sqllib/db2profile. For example:
  • Add the following to the bottom of the $HOME/.profile
. /<db2home>/sqllib/db2profile
Note: <dot><space>/full/path/sqllib/db2profile
  • Add the following to the bottom of the $HOME/.bash_profile
source /<db2home>/sqllib/db2profile
  • By default, the .../sqllib/db2profile sources the .../sqllib/userprofile. Therefore, the DSMI variables will still be exported into the DB2 user's shell.
  • To avoid confusion, it is recommended to remove the DSMI variables from the $HOME/.profile or $HOME/.bash_profile (if they exist) and only define the DSMI variables in the .../sqllib/userprofile

4. If using passwordaccess generate (in the dsm.sys), the DB2 database configuration parameters TSM_OWNER, TSM_NODE, and TSM_PASSWORD must be set to NULL. To verify, run:
db2 get db cfg for dbname | grep TSM
TSM management class (TSM_MGMTCLASS) = MYDB2CLASS
TSM node name (TSM_NODENAME) =
TSM owner (TSM_OWNER) =
TSM password (TSM_PASSWORD) =
  • The query will show blank values for the parameters that are already NULL.
  • If you need to update any of these DB2 database configuration parameters, run:
db2 update db cfg for dbname using TSM_NODENAME NULL
  • The value for TSM_MGMTCLASS will not affect this sign-in or authentication, so it can be either NULL or populated with a valid management class. The mgmtclass specified will only be used for the DB2 database backups, not the db2 logs.
  • The TSM_OWNER, TSM_NODE, and TSM_PASSWORD parameters should only be populated when passwordaccess is set to prompt within the dsm.sys file.

5. Log out and log back in again as the DB2 user to set the environment

6. Verify the DSMI environment variables by running:
set | grep DSMI

7. Switch to the root user by running:
su
  • Note: do not use the "-". This will maintain the DB2 environment variables.

whoami
  • Verify that you are root

set | grep DSMI
  • Verify that the DSMI environment variables are still set appropriately

$HOME/sqllib/adsm/dsmapipw
  • Set the password for this TSM Node
  • If this fails,
    1. Ensure the password being specified is correct or update the password on the TSM Server with the command: UPDATE NODE the-tsm-nodename-for-db2 NewPassword
    2. If passworddir is specified in the dsm.sys, delete the TSM.PWD file in this directory
  • then run dsmapipw again.

exit
  • You should now be the DB2 user id again

db2adutl query
  • This should complete successfully, which verifies that the environment in the current shell is properly configured

8. Recycle the DB2 instance so that the proper DSMI variables will be picked up by the DB2 instance

9. Run the backup from DB2. For example:
db2 backup db dbname use TSM

DB2 Configuring an HADR Environment

Configuring an HADR Environment

Hello guys, this is a tutorial that I found regarding HADR enablement that I thought very usefull when I needed it. Have a good practice! Source: http://db2nerd.blogspot.com/2008/08/ibm-db2-hadr-example.html
For the intent of all purposes, I installed a fresh copy of DB2 ESE version 9 and chooose NOT to create the default DB2 instance. Windows environment is assumed.


Step 1: Create 2 DB2 Instances

Open up an instance of DB2 Command Window by typing "db2cmd" in Run dialog.

Create Instance 1 by typing "db2icrt DB2INST1"

Create Instance 1 by typing "db2icrt DB2INST2"


Step 2: Configure Instance 1

Type the following commands:

SET DB2INSTANCE=DB2INST1
db2set DB2COMM=tcpip
db2 update dbm cfg using SVCENAME 41001
db2start


Note: The TCPIP service port for this instance is 41001

Step 3: Configure Instance 2

Type the following commands:

SET DB2INSTANCE=DB2INST2
db2set DB2COMM=tcpip
db2 update dbm cfg using SVCENAME 42001
db2start

Note: The TCPIP service port for this instance is 42001


Step 4: Create the Primary DB in Instance 1

Type the following commands:

SET DB2INSTANCE=DB2INST1
db2 create db BANKFRS
db2 update db cfg for BANKFRS using LOGINDEXBUILD on
db2 update db cfg for BANKFRS using INDEXREC RESTART
db2 update db cfg for BANKFRS using LOGRETAIN on

Note: This step will turn the DB into archival logging mode


Step 5: Create a backup of Primary DB

Type the following commands:

db2 BACKUP DB BANKFRS TO C:\TEMP

Note: This step will backup the BANKFRS db into C:\TEMP


Step 6: Restore the backup BANKFRS as Standby database

Type the following commands:

SET DB2INSTANCE=DB2INST2
db2 RESTORE DB BANKFRS FROM C:\TEMP

Note: This step will restore the database as BANKFRS in the second DB2 instance and place it into roll forward pending state.

Note: If you roll forward the BANKFRS now, you will not be able to initialize it as the standby database.


Step 7: Configure the HADR settings for the Primary DB in DB2INST1

Type the following commands:

SET DB2INSTANCE=DB2INST1
db2 update alternate server for database BANKFRS using hostname localhost port 42001
db2 update db cfg for BANKFRS using hadr_local_host localhost
db2 update db cfg for BANKFRS using hadr_local_svc 41005
db2 update db cfg for BANKFRS using hadr_remote_host localhost
db2 update db cfg for BANKFRS using hadr_remote_svc 42005
db2 update db cfg for BANKFRS using hadr_remote_inst DB2INST2
db2 update db cfg for BANKFRS using hadr_syncmode SYNC
db2 update db cfg for BANKFRS using hadr_timeout 120

Note: Primary BANKFRS HADR service port will be 41005.
Note: Standby BANKFRS HADR service port will be 42005.
Warning: You cannot use the Instance TCPIP port (SVCENAME) or next port number (SVCENAME+1) as the HADR service port. This is by design.


Step 7: Configure the HADR settings for the Primary DB in DB2INST1

Type the following commands:

SET DB2INSTANCE=DB2INST1
db2 update alternate server for database BANKFRS using hostname localhost port 41001
db2 update db cfg for BANKFRS using hadr_local_host localhost
db2 update db cfg for BANKFRS using hadr_local_svc 42005
db2 update db cfg for BANKFRS using hadr_remote_host localhost
db2 update db cfg for BANKFRS using hadr_remote_svc 41005
db2 update db cfg for BANKFRS using hadr_remote_inst DB2INST1
db2 update db cfg for BANKFRS using hadr_syncmode SYNC
db2 update db cfg for vusing hadr_timeout 120

Note: Primary BANKFRS HADR service port will be 41005.
Note: Standby BANKFRS HADR service port will be 42005.
Warning: You cannot use the Instance TCPIP port (SVCENAME) or next port number (SVCENAME+1) as the HADR service port. This is by design.


Now, you are ready to test the configuration.


Step 8: Start HADR on Standby DB IN DB2INST2

SET DB2INSTANCE=DB2INST2
db2 START HADR ON DB BANKFRS AS STANDBY


Step 9: Start HADR on Primary DB IN DB2INST1

SET DB2INSTANCE=DB2INST1
db2 START HADR ON DB BANKFRS AS PRIMARY


Step 10: Take over the Primary Role to Standby Instance

SET DB2INSTANCE=DB2INST2
db2 TAKEOVER HADR ON DB BANKFRS


Step 11: Take back the Primary Role from Standby Instance

SET DB2INSTANCE=DB2INST1
db2 TAKEOVER HADR ON DB BANKFRS

Step 12: Stop the HADR service on Primary DB

SET DB2INSTANCE=DB2INST1
db2 STOP HADR ON DB BANKFRS


Step 13: Stop the HADR service on Standby DB

SET DB2INSTANCE=DB2INST2
db2 deactivate db BANKFRS
db2 STOP HADR ON DN BANKFRS

Authorization or Privilege problem with ALTER MODULE

Authorization or Privilege problem with ALTER MODULE

When you try to execute a command with all privileges possible and you get an authorization or privilege error, you have to check if the command require you be the owner of the object.

One of this commands is the ALTER MODULE, see the example below:

labdb201@server1:~$ db2 "ALTER MODULE  schema1.Module add TYPE ITEMLIST AS INTEGER ARRAY [VARCHAR(100)]"

DB21034E  The command was processed as an SQL statement because it was not a 
valid Command Line Processor command.  During SQL processing it returned:
SQL0551N  "LABDB201" does not have the required authorization or privilege to 
perform operation "ALTER MODULE" on object "MODULO2.SALESMODULE2".  LINE 
NUMBER=3.  SQLSTATE=42501



How to fix the problem above



You have to drop the object, in our example, drop the module and recreate it or you have to execute the command as owner of object.

To find out who is the object owner, execute the command below:

select owner from syscat.modules where moduleschema='SCHEMA1' and modulename='MODULE'"

Sunday, 27 October 2024

How to discover the number of columns from your table

How to discover the number of columns from your table

db2 "select count(*) from syscat.columns where tabschmema='<schema_name>' and tabname='<tab_name>'"

Checking Useful Backup Information

Checking Useful Backup Information

How to proceed if you need to check some information about your backup, such as what kind of backup it is (online, offline, incremental, full or delta) and what was the logs used during the backup image process
If you need information about backup images, such as type and range of logs used, perform the following command:

db2 list history backup all for <db_name>

It will show you all information about the backup images created recently.

Example:
db2 list history backup all for DBASE1

                    List History File for DBASE1

Number of matching file entries = 3


 Op Obj Timestamp+Sequence Type Dev Earliest Log Current Log  Backup ID
 -- --- ------------------ ---- --- ------------ ------------ --------------
  B  D  20080331213002001   N    D  S0030133.LOG S0030134.LOG
 ----------------------------------------------------------------------------
  Contains 9 tablespace(s):

  00001 SYSCATSPACE
  00002 USERSPACE1
  00003 TS_RECORD
  00004 TS_ENVIRONMENT
  00005 TS_SLOTS
  00006 TS_DATA
  00007 TS_INDEXES
  00008 TS_LONG
  00009 SYSTOOLSPACE
 ----------------------------------------------------------------------------
    Comment: DB2 BACKUP DBASE1 ONLINE
 Start Time: 20080331213002
   End Time: 20080331215718
     Status: E
 ----------------------------------------------------------------------------
  EID: 31967 Location: /backup/dbase1_bkp


 Op Obj Timestamp+Sequence Type Dev Earliest Log Current Log  Backup ID
 -- --- ------------------ ---- --- ------------ ------------ --------------
  B  D  20080331213002002   N    D  S0030133.LOG S0030134.LOG
 ----------------------------------------------------------------------------
  Contains 9 tablespace(s):

  00001 SYSCATSPACE
  00002 USERSPACE1
  00003 TS_RECORD
  00004 TS_ENVIRONMENT
  00005 TS_SLOTS
  00006 TS_DATA
  00007 TS_INDEXES
  00008 TS_LONG
  00009 SYSTOOLSPACE
 ----------------------------------------------------------------------------
    Comment: DB2 BACKUP DBASE1 ONLINE
 Start Time: 20080331213002
   End Time: 20080331215718
     Status: E
 ----------------------------------------------------------------------------
  EID: 31968 Location: /backup/dbase1_bkp


 Op Obj Timestamp+Sequence Type Dev Earliest Log Current Log  Backup ID
 -- --- ------------------ ---- --- ------------ ------------ --------------
  B  D  20080331213002003   N    D  S0030133.LOG S0030134.LOG
 ----------------------------------------------------------------------------
  Contains 9 tablespace(s):

  00001 SYSCATSPACE
  00002 USERSPACE1
  00003 TS_RECORD
  00004 TS_ENVIRONMENT
  00005 TS_SLOTS
  00006 TS_DATA
  00007 TS_INDEXES
  00008 TS_LONG
  00009 SYSTOOLSPACE
 ----------------------------------------------------------------------------
    Comment: DB2 BACKUP DBASE1 ONLINE
 Start Time: 20080331213002
   End Time: 20080331215718
     Status: E
 ----------------------------------------------------------------------------
  EID: 31969 Location: /backup/dbase1_bkp


As you can see, it is possible with the command to check several information about the created backup images, such as which tablespaces was made backup, what was the range of log files used, the directory where the image was created, the backup type and the start / end time of the backup process. 

Some of the important information in the history file is:

Op
    This is the operation that was performed. In the exampled above it is a "B" which stands for backup. A list of the possible values for Op can be found in the Command Reference under the LIST HISTORY command. 

Obj
    This is the granularity of the backup. "D" for database backup . "T" for tablespace backup. 

Earliest Log
    In the case of an online backup, this is the first log required for the rollforward operation. 

Current Log
    The last log that was written to when the backup completed. In the case of an online backup, this is the minimum log required for the backup to complete.

Type
    For backup operations, type "F" means full offline backup, "N" means full online backup, "I" means incremental offline backup, "O" means incremental online backup, "D" means delta offline backup and "E" means delta online backup.

The status of a backup operation: A - active, I - inactive, E - expired, or D - deleted