You are on page 1of 59

IBM Cloud and Smarter Infrastructure

Tivoli Storage Manager


Database Tips
Dave Minch, Senior Software Engineer, Tivoli Storage Manager Server, minch@us.ibm.com

IBM Cloud and Smarter Infrastructure | Tivoli Storage Manager server

Agenda

Db2 tablespaces
Server-initiated Reorganization
Database Growth - APAR IC82886
LockWait problems
IC95301 Disabling Reorg on certain tables
Db2diag.log tips
Db2pd utility for problem determination
Grep
Deduplication and Reorganization
Reorg Technote: http://www.ibm.com/support/docview.wss?
uid=swg21452146

Server Education

IBM Cloud and Smarter Infrastructure | Tivoli Storage Manager server

DB2 Tablespaces
The database is composed of tablespaces
For V6-formatted servers, tablespace 2 is for the majority of the

tables; tablespace 4 are the indices for tables in tablespace 2;


tablespace 5 are the large tables; tablespace 6 are the indices for
the large tables.
V7-formatted servers have the 4 largest tables with their data in one
tablespace and their indices in another tablespace. All the other
tables are as in V6.
As configured by server, these tablespaces have no upper bound for
sizethey grow as needed.
Servers formatted with V6.1 have DB2 9.5 tablespacesthey are
not upgraded when the server is upgraded. V6.2, V6.3, and V7
servers have DB2 9.7 tablespaces.

Server Education

IBM Cloud and Smarter Infrastructure | Tivoli Storage Manager server

DB2 Tablespaces DB2 9.7 tablespaces


V9.7 tablespaces have the reclaimable space feature which is key
to being able to recover freed space in the database. Customers
running servers with V9.5 tablespaces can run reorganization and
not see any space savings.
For customers who originally formatted servers with V6.1, we
provide scripts to convert the database to V9.7 tablespaces:
These require that the server be halted while the reconfiguration is
being done.
They export all the table data into flat files, drop all the
tables/indices/tablespaces/etc., create new 9.7 tablespaces, and
rebuild the tables/indices/views/etc. and import the data back in.

Server Education

IBM Cloud and Smarter Infrastructure | Tivoli Storage Manager server

DB2 Tablespaces Script conversion


O/S

DB size before DB size after

#hours

Windows

550

130

13

AIX

465

228

15 (but exported to
NFS mounted fs)

Linux

1525

410

28

Server Education

IBM Cloud and Smarter Infrastructure | Tivoli Storage Manager server

DB2 Tablespaces - MON_GET_TABLESPACE


MON_GET_TABLESPACE can be used to get information on db2
tablespaces.
Columns of interest are the page size, total pages being used, and
the number of free pages.
SELECT varchar(tbsp_name,16), tbsp_page_size,
tbsp_total_pages, tbsp_free_pages
FROM TABLE(MON_GET_TABLESPACE('',-2))
WHERE TBSP_TYPE='DMS'
ORDER BY tbsp_free_pages DESC;

Server Education

IBM Cloud and Smarter Infrastructure | Tivoli Storage Manager server

DB2 Tablespaces - MON_GET_TABLESPACE

Server Education

IBM Cloud and Smarter Infrastructure | Tivoli Storage Manager server

Reorganizing databases
3 types reorganizing tables, reorganizing the indices for those
tables, doing a CLEANUP PAGES ALL index reorg on
bf_bitfile_extents when F7/F8 are true.
The discussion of reorganizing databases is only relevant on
properly-provisioned machines. Until that is resolved, we cant
continue.
Reorganization Technote:
http://www-.ibm.com/support/docview.wss?uid=swg21452146
Database size, database reorganization, and performance
considerations for Tivoli Storage Manager V6 and V7 servers

Server Education

IBM Cloud and Smarter Infrastructure | Tivoli Storage Manager server

Reorganizing databases Table formulas


Table statistics:
F1: 100 * OVERFLOW / CARD < 5
F2: 100 * (Effective Space Utilization of Data Pages) > 70
F3: 100 * (Required Pages / Total Pages) > 80

Online reorg looks at F1 and F2.

Server Education

IBM Cloud and Smarter Infrastructure | Tivoli Storage Manager server

Reorganizing databases Index formulas


Index statistics:
F4: CLUSTERRATIO or normalized CLUSTERFACTOR > 80
F5: 100 * (Space used on leaf pages / Space available on non-empty
leaf pages) > MIN(50, (100 - PCTFREE))
F6: (100 - PCTFREE) * (Amount of space available in an index with
one less level / Amount of space required for all keys) < 100
F7: 100 * (Number of pseudo-deleted RIDs / Total number of RIDs) <
20
F8: 100 * (Number of pseudo-empty leaf pages / Total number of leaf
pages) < 20

Server uses F5 to determine whether to do index reorg


Server uses F7/F8 on BF_BITFILE_EXTENTS to do cleanup

Server Education

IBM Cloud and Smarter Infrastructure | Tivoli Storage Manager server

Server Reorg table reorg


If F1 or F2 from the DB2 reorgchk command for a table is true, table reorg
will be run on that table, except as follows:

20 days must have elapsed since the last table reorg was started

If server option ALLOWREORGTABLE is set to NO

The current time is outside of the reorg window indicated by server options
REORGBEGINTIME and REORGDURATION

Table reorg is paused on this table, in which case, it will be resumed during the
next current reorg window.

If an index reorg is running on another table or a CLEANUP index reorg is


running on BF_BITFILE_EXTENTS or another table reorg is running.

Server-initiated runstats is being run on some table.

The server is resolving a lock-wait condition.

A server database backup is running.

Table reorg takes precedence over index reorg

Server Education

IBM Cloud and Smarter Infrastructure | Tivoli Storage Manager server

Server Reorg table reorg


Table reorg runs for an hour and will then be paused. This allows all
the transactions to be committed, and frees the active log.
About five minutes later (if the current time is during the reorg
window), the table reorg is resumed.
After table reorg completes, runstats is initiated by the server on that
table.
After the runstats completes on that table, if the current time is still
during the reorg window, the server reorg module looks for another
table that needs table reorg. If no tables need table reorg, the server
attempts to find tables for which indices need to be reorganized.

Server Education

IBM Cloud and Smarter Infrastructure | Tivoli Storage Manager server

Server Reorg index reorg


If F5 from the DB2 reorgchk command for a table is true, index reorg
will be run on that table, except as follows:
20 days must have elapsed since the last index reorg was started
If server option ALLOWREORGINDEX is set to NO
The current time is outside of the reorg window indicated by server
options REORGBEGINTIME and REORGDURATION
If an index reorg is running on another table or a CLEANUP index reorg
is running on BF_BITFILE_EXTENTS or another table reorg is running.
Server-initiated runstats is being run on some table.
The server is resolving a lock-wait condition.
A server database backup is running.

Server Education

IBM Cloud and Smarter Infrastructure | Tivoli Storage Manager server

Server Reorg index reorg


After index reorg completes, runstats is initiated by the server on
that table.
After the runstats completes on that table, if the current time is still
during the reorg window, the server reorg module looks for another
table that needs index reorg.
Index reorg cannot be pausedit runs to completion; thus, if an
index reorg is running and the current time is outside of the reorg
window, the reorg continues.

Server Education

IBM Cloud and Smarter Infrastructure | Tivoli Storage Manager server

Server Reorg index reorg (cleanup)


When large amounts of dedup data are deleted from storage pools,

F7 and/or F8 can become true for the indices for


BF_BITFILE_EXTENTS. This can cause a performance problem.
See APAR IC82352.
When the server starts, the reorg module starts a separate thread
that monitors BF_BITFILE_EXTENTS. If this condition is discovered,
an index CLEANUP PAGES ALL reorg is run on that table.
This is done irrespective of any server options.
But after that IC82352 went to the field, we found that DB2 does the
whole cleanup reorg under one transaction and that can cause the
server to halt with a full active log (IC91190).
IC91190 in 6.2.6, 6.3.5, and 7.1.0 fixes the problem.
IC95301 will allow this thread to be disabled, but that doesnt ship
until 6.3.5 and 7.1.1.

Server Education

IBM Cloud and Smarter Infrastructure | Tivoli Storage Manager server

Reorganization - Activity Log Messages


Table Reorg Messages

ANR0293I Reorganization for table AF_BITFILES started.

ANR0294I Reorganization for table AF_BITFILES ended.

Index Reorg messages

ANR0317I Reorganization of indices for table GROUP_LEADERS started.

ANR0318I Reorganization of indices for table GROUP_LEADERS ended with


sqlCode 0. (Since index reorg is synchronous, we have a sqlCode)

Runstats Messages

ANR0336I Runstats for table AS_SEGMENTS started.

ANR0337I Runstats for table AF_SEGMENTS ended with sqlCode 2314.

(Note that the 2314 is innocuous. With a large busy table not all the statistics
could be gathered, but sufficient were gathered.

Server Education

IBM Cloud and Smarter Infrastructure | Tivoli Storage Manager server

Server Reorg and busy tables


Reorg running while the server runs needs to ensure that the server

has access to the rows while reorg works.


Thus, reorg works on groups of rows.
Reorg copies a group of rows, works on them, and when all the
readers/writers (from other server processes) exit, reorg can replace
the old rows with the new rows.
A very active table, consequently, will experience difficulties having
on-line reorg run on it.
Some problematic tables never have table reorg run on them:
STAGED_EXPIRING_OBJECTS, STAGED_OBJECT_IDS,
BF_DEREFERENCED_CHUNKS, and BF_QUEUED_CHUNKS.
Index reorg is disabled for the following tables: All the tables
disabled for table reorg and REPLICATING_OBJECTS and
REPLICATED_OBJECTS

Server Education

IBM Cloud and Smarter Infrastructure | Tivoli Storage Manager server

Obtaining current database reorg status


http://www-01.ibm.com/support/docview.wss?uid=swg21590928 is the reorg
must gather doc.
Theres perl script attached to this document which gathers up all the
relevant information - serverReorgInfo.pl
If you believe there is a reorg problem, run this script.
The most commonly used items from the data gather are the files:

db2pd-tablespace.txt (output from the db2pd tablespace cmd)

db2reorgchk.out (output from the db2 reorgchk command)

Open a PMR and provide the data to TSM L2.

Server Education

IBM Cloud and Smarter Infrastructure | Tivoli Storage Manager server

Diagnosing Database Growth reorgchk output


This is some DB2 reorgchk output:

SCHEMA.NAME
CARD
OV
NP
FP ACTBLK
TSIZE F1 F2 F3 REORG
--------------------------------------------------------------------<lots of system table outputs>
Table: TSMDB1.BF_AGGREGATED_BITFILES
6,1e+08 2e+07 3e+06 3e+06
4,10e+10
2 90 97 ---

<other table output>


<then the indices>

Server Education

IBM Cloud and Smarter Infrastructure | Tivoli Storage Manager server

Diagnosing Database Growth reorgchk output


SCHEMA.NAME
INDCARD LEAF ELEAF LVLS NDEL
KEYS
LEAF_RECSIZE NLEAF_RECSIZE LEAF_PAGE_OVERHEAD
NLEAF_PAGE_OVERHEAD PCT_PAGES_SAVED F4 F5 F6 F7 F8 REORG
..
<system indices>
Table: TSMDB1.BF_AGGREGATED_BITFILES
Index: TSMDB1.BFBF_ABBRV_NDX
6,1e+08 3e+06 19679
4 2e+08 2,4e+08
12
12
866
866
25 95 31
8 22
0 -*-*Index: TSMDB1.BFBF_NDX
6,1e+08 5e+06 59589
5 2e+08 6,1e+08
20
20
654
654
16 95 40 420 22
1 -***-

<other indices for that table>


<other table indices>

Server Education

IBM Cloud and Smarter Infrastructure | Tivoli Storage Manager server

Tsize distributions for typical databases


Note how the tSizes decrease rapidly table by table. This is a server running
deduplication, but similar distributions appear for non-dedup servers, but for
them BACKUP_OBJECTS and/or ARCHIVE_OBJECTS tend to be the
biggest tables.
Table
Table
Table
Table
Table
Table
Table
Table
Table
Table

BF_AGGREGATED_BITFILES, reorg=-*-(0,68,97), tsize=128746.0M


BF_BITFILE_EXTENTS,
reorg=---(0,86,95), tsize=113487.2M
BACKUP_OBJECTS,
reorg=---(3,100,99), tsize=58841.7M
REPLICATING_OBJECTS,
reorg=--*(0,99,80), tsize=14400.5M
ARCHIVE_OBJECTS,
reorg=---(4,100,95), tsize=12016.3M
GROUP_LEADERS,
reorg=---(0,78,92), tsize=7238.4M
REPLICATED_OBJECTS,
reorg=---(0,87,99), tsize=7104.9M
AS_SEGMENTS,
reorg=---(0,97,99), tsize=2222.1M
ACTIVITY_LOG,
reorg=-**(0,23,25), tsize=1192.1M
AF_BITFILES,
reorg=---(0,100,99), tsize=546.5M

Server Education

IBM Cloud and Smarter Infrastructure | Tivoli Storage Manager server

When reorg doesnt start


Reorg doesnt start if:
Reorg is disabled (server options ALLOWREORGTABLE and/or
ALLOWREORGINDEX are set to NO)
Not during the reorg window
A database backup is running
An ondemand reorg is running
Nothing to reorganize

Server Education

IBM Cloud and Smarter Infrastructure | Tivoli Storage Manager server

Db2pd reorg index


This gives information on both table and index reorgs. (-reorg just gives table
reorg information).
Remember that db2pd only gives information since the instance started.

Server Education

IBM Cloud and Smarter Infrastructure | Tivoli Storage Manager server

Db2pd reorg index

Server Education

IBM Cloud and Smarter Infrastructure | Tivoli Storage Manager server

Db2pd reorg index

Server Education

IBM Cloud and Smarter Infrastructure | Tivoli Storage Manager server

Db2pd reorg index Reorg taking forever


Check the currCount and the maxCount fields. For very large tables,
progress can be very slowrecommend offline reorg for these
cases.

Server Education

IBM Cloud and Smarter Infrastructure | Tivoli Storage Manager server

Db2pd reorg index normal table reorg

Server Education

IBM Cloud and Smarter Infrastructure | Tivoli Storage Manager server

Db2 list history for reorg all

Server Education

-- for table reorg

IBM Cloud and Smarter Infrastructure | Tivoli Storage Manager server

Db2 list history reorg all for tsmdb1

Server Education

-- for table reorg

IBM Cloud and Smarter Infrastructure | Tivoli Storage Manager server

Db2 list history reorg all for tsmdb1 -- for index reorg

Server Education

IBM Cloud and Smarter Infrastructure | Tivoli Storage Manager server

Database Growth Trends


Servers that are running deduplication tend to have huge
BF_BITFILE_EXTENTS and BF_AGGREGATED_BITFILES tables,
with growth especially in the indices. The clustered index on
BF_AGGREGATED_BITFILES that causes the table to be
appended with new rows, and reorg has no effect. This is fixed with
APAR IC82886.
Non-dedup databases tend to have the biggest tables being
BACKUP_OBJECTS, ARCHIVE_OBJECTS, etc.
Most of the data in the server database is in a handful of tables.

Server Education

IBM Cloud and Smarter Infrastructure | Tivoli Storage Manager server

BF_AGGREGATED_BITFILES remove clustered index

IC82886

With dedup, lots of deletion of older rows in this table, but not
enough deletions to merge adjacent pages, and that new rows have
keys that are strictly increasing, this can cause this table to grow
without bound.
Reorg doesnt resolve the problem since a clustered index leaves
space on the page for rows to be re-inserted againthis wont
happen because the keys are strictly increasing. So there are many
almost-empty pages over time.
For newly formatted servers when running with the fixing level, that
index will be created correctly.
For servers upgraded, theres manual procedure to drop that
clustered index and to redefine it as an unclustered index.
http://www.ibm.com/support/docview.wss?uid=swg21592404

Server Education

IBM Cloud and Smarter Infrastructure | Tivoli Storage Manager server

An overview of handling lockwait problems.


The basic premise of online reorg is that the server continues

working, but reorg also progresses too.


DB2 online reorg allows this to happen by making copies of groups
of rows, reorganizing them, then swapping to the reorganized group
of rows. The server continues to operate because the original rows
are available to the server.
Server long-running processes tend to work in this manner:
Theres a readonly transaction determining what work to do.
As needed, readWrite transactions (generally short lived) are started to
do that actual work. After the readWrite transaction completes, the
readonly transaction finds more work to do. This repeats until the
readonly transaction finishes.
The readonly transaction can run for many hours or even days before
ending. Readonly transactions get IN (intent locks) on the tables of
interest.

Server Education

IBM Cloud and Smarter Infrastructure | Tivoli Storage Manager server

An overview of handling lockwait problems.


DB2 cant swap the reorganized rows with the un

reorganized rows when theres a read-only transaction on the


table of interest. So reorg goes into a lock-wait.
Unfortunately, reorg can hold other locks on that table that
will prevent server read-write transactions from getting X
locks on that table. Then the read-write transaction goes into
lock-wait.
We are then deadlocked.
When theres a deadlock, some transaction or transactions
need to be aborted to resolve the deadlock.
The method the lockwait resolution reorg code works is to
cancel transactions one-by-one until the reorg gets out of
lockWait.

Server Education

IBM Cloud and Smarter Infrastructure | Tivoli Storage Manager server

Server APAR IC81261/IC83725


These are the APARs to fix when reorg gets stuck in a lock-wait.
Diagnose with db2 get snapshot for all applications >application.out
and look for db2reorg or Reorganize application and look for it
being in lock-wait.
6.3.4.100 and 7.1.0 final fixing levels

Server Education

IBM Cloud and Smarter Infrastructure | Tivoli Storage Manager server

IC95301- selectively disabling reorg


This APAR (6.3.5/7.1.1) allows disabling of table reorg and index
reorg on specific tables via server options.
Use server option DISABLEREORGTable <tablelist> to disable table
reorg. For example,
DISABLEREORGT bf_bitfile_extents,as_volume_status
Use server option DISABLEREORGIndex <tablelist> to disable
index reorg. For example,
DISABLEREORGI bf_bitfile_extents,as_volume_status
Use server option
DISABLEREORGCleanupindex BF_BITFILE_EXTENTS
to prevent the CLEANUP reorg on that table. DB2 does this reorg in
one transaction and can cause the server to halt with a full active
log. (To be fixed in DB2 APAR IC91020).

Server Education

IBM Cloud and Smarter Infrastructure | Tivoli Storage Manager server

IC95301- Warning reorg messages


For tables excluded by those options, the server checks periodically
(at server start and every seven days after) to see if reorg is needed
on the table or indices of the table. If so, the following message is
issued:
ANR3497W, "Reorganization is required on table <table name>. The
reason code is <reasoncode>."
Reason code 1 means table reorg is needed.
Reason code 2 means index reorg is needed
Reason code 3 means CLEANUP index reorg is needed.

Server Education

IBM Cloud and Smarter Infrastructure | Tivoli Storage Manager server

IC95301- automatic setup


The first time a server with this APAR is started, it will set the
following server options:
The ALLOWREORGINDEX option is set to YES in the server
options file. This enables index reorganization in the server.
The DISABLEREORGTABLE option is set in the server options files
with no table names specified. This means that if
ALLOWREORGTABLE is set to YES, all tables are eligible for table
reorganization processing.
The DISABLEREORGINDEX option is set in the server options file
to BF_AGGREGATED_BITFILES,BF_BITFILE_EXTENTS. This
excludes these two tables from index reorganization processing.

Server Education

IBM Cloud and Smarter Infrastructure | Tivoli Storage Manager server

IC95301- LocalFix until APAR available


Other information is in the Reorg Technote:

http://www.ibm.com/support/docview.wss?uid=swg21452146
The Technote also includes information on disabling table and index
reorg by modifying global variablesthis will be useful until
customers have the fixing levels for the APAR.
The first time: db2 "insert into tsmdb1.global_attributes
(owner,name,type,length,datetime)
values('RDB','<globalVar>',5,6,current date)
Every 19 days afterwards:
db2 "update tsmdb1.global_attributes set datetime=current date
where owner='RDB' and name='<globalVar>' "
globalVar is REORG_TB_tablename for a table,
REORG_IX_tablename

Server Education

IBM Cloud and Smarter Infrastructure | Tivoli Storage Manager server

db2diag.logs
Located in SQLDUMP directory.
With new servers there may be several files of name db2diag.NN.log. When

one log gets to a certain size, another log is created.


This file is where information pertaining to DB2 is written.
Often if DB2 can recover from a problem without informing application (the
server), it will, but it'll write messages to db2diag.log.
Sometimes db2 problems can manifest themselves as performance problems
on the server.
If youre not sure that its a server problem, its always good to examine the
db2diag.log to see how DB2 is doing.
Extracting
Extracting
Extracting
Extracting
Extracting
Server Education

DB2DUMP\db2diag.log
DB2DUMP\db2diag.0.log
DB2DUMP\db2diag.1.log
DB2DUMP\db2diag.2.log
DB2DUMP\db2diag.3.log

Usually the oldest

Usually the newest

IBM Cloud and Smarter Infrastructure | Tivoli Storage Manager server

Db2diag.log instance start


Theres much good information when the instance starts:
Timestamp
Use eduid to tie entries in
the log togetherlike threadid
Db2 build level

Phys Mem

Watch the free physical memory. If its lower than the minimum
required, that suggests a problem.

Server Education

IBM Cloud and Smarter Infrastructure | Tivoli Storage Manager server

Db2diag.log and grep


For example, if you want to know how much free memory is available each
time the instance starts:

Even though theres


16G of memory,
most of its in use
when the instance
starts!

Server Education

IBM Cloud and Smarter Infrastructure | Tivoli Storage Manager server

Db2diag.log FODC information


2012-06-03-13.36.30.039000-420 E18294014F999
LEVEL: Critical
PID
: 14496
TID : 10504
PROC : db2syscs.exe
INSTANCE: SERVER1
NODE : 000
DB
: TSMDB1
APPHDL : 0-43077
APPID: *LOCAL.SERVER1.120603203517
AUTHID : ADMINISTRATOR
EDUID
: 10504
EDUNAME: db2agent (TSMDB1)
FUNCTION: DB2 UDB, base sys utilities, sqeLocalDatabase::MarkDBBad, probe:10
MESSAGE : ADM14001C An unexpected and critical error has occurred:
"DBMarkedBad". The instance may have been shutdown as a result.
"Automatic" FODC (First Occurrence Data Capture) has been invoked
and
diagnostic information has been recorded in directory
"C:\ProgramData\IBM\DB2\DB2TSM1\SERVER1\FODC_DBMarkedBad_2012-06-031
3.36.30.039000_0000\". Please look in this directory for detailed
evidence about what happened and contact IBM support if necessary to
diagnose the problem.

Server Education

IBM Cloud and Smarter Infrastructure | Tivoli Storage Manager server

Db2diag.log Other critical errors


2012-09-09-01.03.10.529058-240 E3396792E1464
LEVEL: Critical
PID
: 13716
TID : 140139258963712PROC : db2sysc 0
INSTANCE: tsminst1
NODE : 000
EDUID
: 1
EDUNAME: db2sysc 0
FUNCTION: DB2 UDB, oper system services, sqloEDUCodeTrapHandler, probe:90
MESSAGE : ADM14011C A critical failure has caused the following type of
error:
"Trap". The DB2 database manager cannot recover from the failure.
First Occurrence Data Capture (FODC) was invoked in the following
mode: "Automatic". FODC diagnostic information is located in the
following directory:
"/home/tsminst1/sqllib/db2dump/FODC_Trap_2012-09-0901.03.07.464953_0000/".

Server Education

IBM Cloud and Smarter Infrastructure | Tivoli Storage Manager server

Db2diag.log
Running out of disk space is very bad.
Its even worse if the filesystem that runs out of space is the one that
db2diag.log resides on

Scan for DIA8312C in db2diag.log

Server Education

IBM Cloud and Smarter Infrastructure | Tivoli Storage Manager server

Db2diag.log
2012-10-26-19.01.45.842623-240 E3797A737
LEVEL: Error (OS)
PID : 9044114
TID : 4885
PROC : db2sysc 0
INSTANCE: tsm011
NODE : 000
EDUID : 4885
EDUNAME: db2pclnr (TSMDB1) 0
FUNCTION: DB2 UDB, oper system services, sqloLioAIOCollect,
probe:100
MESSAGE : ZRC=0x850F000C=-2062614516=SQLO_DISK "Disk
full."
DIA8312C Disk was full.
CALLED : OS, -, aio_return
OSERR : ENOSPC (28) "No space left on device"
Note the EDUID and find associated messages.

Server Education

IBM Cloud and Smarter Infrastructure | Tivoli Storage Manager server

Db2diag.log
2012-10-26-19.01.45.828204-240 E1507A775
LEVEL: Error
PID : 9044114
TID : 4885
PROC : db2sysc 0
INSTANCE: tsm011
NODE : 000
EDUID : 4885
EDUNAME: db2pclnr (TSMDB1) 0
FUNCTION: DB2 UDB, buffer pool services, sqlbClnrAsyncWriteCompletion,
probe:0
MESSAGE : ADM6017E The table space "LGTMPTSP" (ID "7") is full.
Detected on
container
"/tsmdbs/tsm011/db7/tsm011/NODE0000/TSMDB1/T0000007/C0000006.T
MP" (ID
"6"). The underlying file system is full or the maximum allowed
space usage for the file system has been reached. It is also possible
that there are user limits in place with respect to maximum file size
and these limits have been reached.

Server Education

IBM Cloud and Smarter Infrastructure | Tivoli Storage Manager server

Db2diag.log
2013-03-15-17.58.52.667168+060 E28772723E1027
LEVEL: Warning
PID : 11355
TID : 139949756114688PROC : db2sysc 0
INSTANCE: tsminst1
NODE : 000
DB : TSMDB1
APPHDL : 0-15788
APPID: *LOCAL.tsminst1.130602191844
AUTHID : TSMINST1
EDUID : 5555
EDUNAME: db2agent (TSMDB1) 0
FUNCTION: DB2 UDB, buffer pool services, sqlbReadPage, probe:1180
MESSAGE : ADM6000E DB2 encountered a read error while reading page "50065562"
from tablespace "4" for object "19" (located at offset "12516442" of
container
"/tsmbox/db/db1/tsminst1/NODE0000/TSMDB1/T0000004/C0000000.LRG"). DB2
was able to bypass the error by re-reading the page, but this may
indicate the presence of a serious problem that could result in a
future outage. You may wish to begin an investigation of the hardware
(such as disk, controllers, network) and/or the filesystem involved
in accessing the container.

Server Education

IBM Cloud and Smarter Infrastructure | Tivoli Storage Manager server

Db2diag.log
Lock Escalations with small # of locks when running dedup (this happens when

another thread running some LARGE dedup process has almost all the locks, and this
thread just needs a few, but it exceeds the total limit).
Probably needs to have the lockList tuned:
http://www-01.ibm.com/support/docview.wss?uid=swg21430874
2012-11-04-12.27.50.426000-420 E2915979F1540
LEVEL: Warning
PID : 2920
TID : 1856
PROC : db2syscs.exe
INSTANCE: SERVER1
NODE : 000
DB : TSMDB1
APPHDL : 0-1173
APPID: *LOCAL.SERVER1.121104192748
AUTHID : TSMBACKUP
EDUID : 1856
EDUNAME: db2agent (TSMDB1)
FUNCTION: DB2 UDB, data management, sqldEscalateLocks, probe:1
MESSAGE : ADM5501I DB2 is performing lock escalation. The affected application
is named "dsmsvc.exe", and is associated with the workload name
"SYSDEFAULTUSERWORKLOAD" and application ID
"*LOCAL.SERVER1.121104192748" at member "0". The total number of
locks currently held is "8", and the target number of locks to hold
is "4".

Server Education

IBM Cloud and Smarter Infrastructure | Tivoli Storage Manager server

Db2pd DB2 Problem Determination


db2pd- Monitor and troubleshoot db2 database.
Monitors while the instance is running
Unobtrusive, wont hurt server performance.
For tablespaces db2pd -d tsmdb1 <subcommand>

Server Education

IBM Cloud and Smarter Infrastructure | Tivoli Storage Manager server

db2pd -tcbstats

Returns information about tables and indexes.


This is often useful if you believe your workload

is static, but the database keeps growing.


db2pd -d tsmdb1 -full -tcbstats all >tcbstats.out
The second stanza of output TCB Table Stats:
contains the information of interest.
The stats are cumulative since the instance starts
(unless the reset subcommand is used). Thus
running at 6 am then at noon, you can compare
what happened during the last 6 hours.

Server Education

IBM Cloud and Smarter Infrastructure | Tivoli Storage Manager server

db2pd -tcbstats

Watch for #deletes less than #inserts


Server Education

IBM Cloud and Smarter Infrastructure | Tivoli Storage Manager server

db2pd -tcbstats

Sometimes grep and awk can help analyze.


Assume many invocations of db2pd tcbstats
have been saved in tsmstatsoutput.txt
grep -i 'bf_aggregated_bitf' tsmstatsoutput.txt
>bfaggronly.out
cat bfaggronly.out | awk '$2 ~
/BF_AGGREGATED_BITF/ && $3 ~ /TSMDB1/
{ print $11,$12,$13, $11-$13}'
>baggonly.stats.out
Server Education

IBM Cloud and Smarter Infrastructure | Tivoli Storage Manager server

db2pd -tcbstats
Cat baggonly.stats.out
insCat baggonly.stats.out
inserts
updates

deletes

inserts-deletes

2638204605 1227473745 2582301198 55903407


2671098611 1227862694 2585928559 85170052
2708030500 1253009313 2642934742 65095758
2736903960 1253406321 2647105311 89798649
2773582775 1277518311 2701345917 72236858
2802100195 1279964146 2705784129 96316066
2850816064 1297078809 2769652563 81163501
2906367541 1306104941 2815465490 90902051
Server Education

IBM Cloud and Smarter Infrastructure | Tivoli Storage Manager server

Your good friend grep Find all the


Errors
egrep "ANR[0-9]{4}E actlog.txt
04/03/13 08:00:31 ANR0159E tbrsql.c(1430): Database deadlock
detected on 40:15.
04/03/13 08:00:31 ANR0103E bfcreate.c(5330): Error 19 updating row
in table "BF.Aggregated.Bitfi04/03/13 08:00:31 ANR1181E bftxn.c(517): Data storage transaction
0:58798 was aborted.
04/03/13 08:00:31 ANR0159E imbkins.c(6661): Database deadlock
detected on 366:11.
04/03/13 08:00:31 ANR0159E imbkins.c(6661): Database deadlock
detected on 334:16.
04/03/13 08:00:31 ANR0159E tbrsql.c(1430): Database deadlock
detected on 621:16.
04/03/13 08:00:31 ANR0103E bfcreate.c(5330): Error 19 updating row
in table "BF.Aggregated.Bitfi-

Server Education

IBM Cloud and Smarter Infrastructure | Tivoli Storage Manager server

Your good friend grep Find all the Reorg Messages


ANR0293, 294, 336, 337, 317, 318
$ egrep "ANR0((29(3|4))|(31(7|8))|(33(6|7)))I" 20130430-1519-actlog.txt
21-04-2013 13:43:54
ANR0294I Reorganization for table BF_BITFILE_EXTENTS
21-04-2013 13:48:55
ANR0336I Runstats for table BF_BITFILE_EXTENTS started.
22-04-2013 05:31:40
ANR0337I Runstats for table BF_BITFILE_EXTENTS ended with
22-04-2013 10:00:58
ANR0293I Reorganization for table ACTIVITY_LOG started.
22-04-2013 10:05:58
ANR0294I Reorganization for table ACTIVITY_LOG ended.
22-04-2013 10:10:59
ANR0336I Runstats for table ACTIVITY_LOG started.
22-04-2013 10:11:20
ANR0337I Runstats for table ACTIVITY_LOG ended with
22-04-2013 10:16:00
ANR0293I Reorganization for table DF_BITFILES started.
22-04-2013 10:21:01
ANR0294I Reorganization for table DF_BITFILES ended.
22-04-2013 10:26:01
ANR0336I Runstats for table DF_BITFILES started. (PROCESS:
22-04-2013 10:26:02
ANR0337I Runstats for table DF_BITFILES ended with sqlCode
22-04-2013 12:36:33
ANR0317I Reorganization for indices for table DS_OVERFLOW
22-04-2013 12:36:34
ANR0318I Reorganization of indices for table DS_OVERFLOW
22-04-2013 12:41:29
ANR0336I Runstats for table DS_OVERFLOW started. (PROCESS:
22-04-2013 12:41:29
ANR0337I Runstats for table DS_OVERFLOW ended with sqlCode

Server Education

IBM Cloud and Smarter Infrastructure | Tivoli Storage Manager server

The dedup script and the reorg connection

http://www.ibm.com/support/ docview.wss?uid=swg21596944

Determining the impact of deduplication on a Tivoli Storage Manager


server database and storage pools

This script can also be used to see if reorg can help free up space.

Server Education

IBM Cloud and Smarter Infrastructure | Tivoli Storage Manager server

The dedup script and the reorg connection


(All sizes in MB)(Output edited to fit on slide)
NAME
#ROWS
TBL_USED TBL_ALLOC IDX_USED IDX_ALLOC
-------------------------------------------------------------------------BF_AGGREGATED_BITFILES
885174332 81411
287817
125683
608486
BF_BITFILE_EXTENTS
436638649 28485
109430
84389
442262
BACKUP_OBJECTS
137561025 48948
49414
34594
35344
GROUP_LEADERS
95597146
3701
5145
4307
9335
BF_DEREFERENCED_CHUNKS
345224
12
32401
31
94925
BF_QUEUED_CHUNKS
117923
14
42375
37
101152

Server Education

IBM Cloud and Smarter Infrastructure | Tivoli Storage Manager server

Thank you for your attention


Open forum

Server Education

You might also like