TSM Server V7.1.

5
Tablespace Conversion

Norbert Pott November 16th, 2016

npott@de.ibm.com
IBM Germany

Developped with Urs Moser of

IBM Switzerland
Tip: Beginning with Version 7.1.3, IBM Tivoli Storage Manager is now IBM
Spectrum Protect. Some applications such as the software fulfillment systems
and IBM License Metric Tool use the new product name. However, the
software and its product documentation continue to use the Tivoli Storage
Manager product name. To learn more about the rebranding transition, see
http://www.ibm.com/support/docview.wss?uid=swg21963634.
Background :
IBM Spectrum Protect tablespaces changed over time:

V6.1.X DB2 V9.5 tablespaces, limited capabilities to free space, 4

tablespaces
V6.2.X DB2 V9.7 tablespaces, enhanced capabilities to free space, 4
tablespaces
V7.1.X DB2 9.7 tablespaces, V7 tablespace layout

For customers that upgraded from an earlier Tivoli Storage Manager level to V7, the
recommendation is to do tablespace conversion, especially if doing dedup.
Clean V7 installations already use the V7 tablespace schema, nothing to do.
Motivation :

why you might want to consider tablespace reorganization:

Remove discrepancies that DB2 9.5 tablespaces have

9.7 tablespaces allow to free up unused space

Take advantage of separate tablespaces for large tables

improve performance in general
improve database backup performance

Note: changes to the DB2 10.5 tablespaces have been reviewed by server
development and currently there is no update required if you are using DB2
9.7 tablespaces.
 Additional new Commands with 7.1.1.xxx
SHOW VERSIONHISTory
Date (GMT) Version Pre-release Driver
-------------------- -------------------- --------------------
2014/11/12 15:26:21 7.1.1.0
2015/02/11 14:15:18 7.1.1.100
2015/06/10 13:02:03 7.1.1.300

The above output is available with the new command, however as this command does not report
any version earlier than V7.1, it does not help to verify if you need to go through tablespace
conversion for either the update of the tablespaces or changing the tablespace allocation
schema.

The following slides help you to verify if you should consider tablespace updates.
 Verify V6.1 DB2 9.5 Tablespaces
Use the following SQL command to verify your server is still using DB2 V9.5
tablespaces:

db2 "select cast(TBSP_NAME as char(30)), reclaimable_space_enabled from

table(mon_get_tablespace('',-1)) where TBSP_NAME in
('USERSPACE1','IDXSPACE1','LARGESPACE1','LARGEIDXSPACE1')"

If the result is 0 for any tablespace, tablespace conversion is indicated to improve

the tablespaces capabilities to free up unused space to the OS.

If the result is 1 for all tablespaces, you are not using DB2 9.5 tablespaces,
but: you might still use the Tivoli Storage Manager V6 tablespace layout!
 Verify APAR IC82886
APAR IC82886 documents the following symptom:
EXCESSIVE DATABASE GROWTH EXPERIENCED WHEN DEDUPLICATION IS
ENABLED UNDER CERTAIN WORKLOADS

If there is a clustering index on the BF_AGGREGATED_BITFILES table, the

following select will return CLUS for INDEXTYPE.

db2 connect to tsmdb1

db2 "select INDEXTYPE from sysibm.sysindexes where name='BFBF_NDX'"

If CLUS is returned, you can follow the local fix recommendations, however
tablespace conversion will fix the symptom too and is the preferred method.
V6.2 / V6.3 Tablespaces 1/2
Use the following SQL command to verify your server is using Tivoli Storage
Manager V6.2/V6.3 tablespace schema:

db2 "select substr(TABSCHEMA,1,20) as schema , substr(TABNAME,1,20) as table,

TBSPACEID, substr(TBSPACE,1,20) as tablespace, substr(index_tbspace,1,20) as indexspace
from syscat.tables where tabschema='TSMDB1' and TABNAME in
('BACKUP_OBJECTS','ARCHIVE_OBJECTS', 'BF_BITFILE_EXTENTS',
'BF_AGGREGATED_BITFILES') order by 3"

SCHEMA TABLE TBSPACEID TABLESPACE INDEXSPACE

-------------------- -------------------- --------- -------------------- --------------------
TSMDB1 BF_AGGREGATED_BITFIL 2 USERSPACE1 IDXSPACE1
TSMDB1 BF_BITFILE_EXTENTS 2 USERSPACE1 IDXSPACE1
TSMDB1 ARCHIVE_OBJECTS 5 LARGESPACE1 LARGEIDXSPACE1
TSMDB1 BACKUP_OBJECTS 5 LARGESPACE1 LARGEIDXSPACE1
 ARCHIVE_OBJECTS

BACKUP_OBJECTS

OTHER TABLES
USERSPACE1

Indices for
ARCHIVE_OBJECTS
Tablespace allocation up to V6.3

Indices for BACKUP_OBJECTS

Indices for OTHER TABLES

IDXSPACE1

BF_AGGREGATED_BITFILES

BF_BITFILE_EXTENTS
V6 tablespaces

OTHER TABLES
Tivoli Storage Manager

LARGESPACE1

Indices for
BF_AGGREGATED_BITFILES

Indices for
BF_BITFILE_EXTENTS

Indices for OTHER TABLES

LARGEIDXSPACE1

 Indices for tables in

others
tables in
Indices for USERSPACE1

others
IDXSPACE1
USERSPACE1

LARGEIDXSPACE1
LARGESPACE1

LARGEIDXSPACE1
Tablespace allocation with V7.1.1

ARCHIVE_OBJECTS
ARCHOBJDATASPACE
ARCHOBJIDXSPACE

BACKUP_OBJECTS
BACKOBJDATASPACE
BACKOBJIDXSPACE

BF_AGGREGATED_BITFILES
BFABFDATASPACE
tablepsaces

BFABFIDXSPACE

BF_BITFILE_EXTENTS
& Spectrum Protect 7.1.3
Tivoli Storage Manager 7.1

BFBFEXTDATASPACE
BFBFEXTIDXSPACE
 V7.1.1 Tablespace Details
New tablespaces schema introduced with Tivoli Storage Manager V7.1
_______________________________________________________________________________________________
| | from | from | to | to |
| tablename | dataTblSpace | idxTblSpace | DataTblspace | IdxTblspace |
| ARCHIVE_OBJECTS | LARGESPACE1 | LARGEIDXSPACE1 | ARCHOBJDATASPACE | ARCHOBJIDXSPACE |
| BACKUP_OBJECTS | LARGESPACE1 | LARGEIDXSPACE1 | BACKOBJDATASPACE | BACKOBJIDXSPACE |
| BF_AGGREGATED_BITFILES | USERSPACE1 | IDXSPACE1 | BFABFDATASPACE | BFABFIDXSPACE |
| BF_BITFILE_EXTENTS | USERSPACE1 | IDXSPACE1 | BFBFEXTDATASPACE | BFBFEXTIDXSPACE |
_______________________________________________________________________________________________

No automatic tablespace conversion during an update of the server as the

conversion is a time consuming process.

Instructions are available to convert the tablespaces, this procedure will ensure that
all tables are allocated in DB2 9.7 tablespaces, and will place all tables in
tablespaces as-if the database had been formatted with server V7.
 V7.1.7 Additional Tables
db2 => select substr(TABSCHEMA,1,20) as schema , substr(TABNAME,1,20) as table, TBSPACEID,
substr(TBSPACE,1,20) as tablespace, substr(index_tbspace,1,20) as indexspace from syscat.tables where
tabschema='TSMDB1' and TBSPACEID>10 order by 3

SCHEMA TABLE TBSPACEID TABLESPACE INDEXSPACE

-------------------- -------------------- --------- -------------------- --------------------
TSMDB1 ARCHIVE_OBJECTS 12 ARCHOBJDATASPACE ARCHOBJIDXSPACE
TSMDB1 BACKUP_OBJECTS 14 BACKOBJDATASPACE BACKOBJIDXSPACE
TSMDB1 BF_AGGREGATED_BITFIL 16 BFABFDATASPACE BFABFIDXSPACE
TSMDB1 BF_BITFILE_EXTENTS 18 BFBFEXTDATASPACE BFBFEXTIDXSPACE
TSMDB1 SD_STGPOOL_DIRECTORI 20 DEDUPTBLSPACE1 DEDUPIDXSPACE1
TSMDB1 SD_CONTAINERS 20 DEDUPTBLSPACE1 DEDUPIDXSPACE1
..
TSMDB1 SD_REPLICATED_CHUNKS 28 DEDUPTBLSPACE5 DEDUPIDXSPACE5
15 record(s) selected.

Only the 4 tables highlighted in blue have to be considered if tablespace conversion is

indicated or not. The other tables are new and came with their own tablespaces when
they were introduced. In the above example conversion is complete.
V7.1 Tablespace Conversion: Schema dependency
Previous to IBM Spectrum Protect 7.1.5 (7.1.6 for Windows servers), the
tablespace conversion used schema dependent scripts.

This has changed and the instructions provided give details on the following
steps:

1. Planning the migration

2. Preparing the source and target systems
3. Converting the server database
Extracting the contents of the database
Dropping the database
Creating an empty database
Inserting the contents into an empty database
V7.1 Tablespace Conversion: Planning disk requirements
The EXTRACT used to write out the database records does not write out index
information, so the expectation is that you need less disk space than what is
currently used by the server database.
Database Total Space Used Space Used Free
Name Space of on File by Database- Space
File System(MB) (MB) Available
System (MB)
(MB)
-------- -------- ---------- ------------ ---------
TSMDB1 917,373 492,011 491,743 425,362

and
ANR3408I EXTRACTDB: Wrote 82,152,541,340 bytes.

Technote: Size considerations when going through EXTRACTDB/INSERTDB

processing - https://ibm.biz/Bdsieu
V7.1 Tablespace Conversion: Planning - when to run
If you are already at a V7.1.5 server (7.1.6 for Windows), you can run the
conversion any time, however if you are not running dedup today, you want to
make sure to complete the conversion before you enable dedup.

The reason for this is that enabling dedup makes the database grow in size,
so you want to complete the conversion while the database is still small.

If you are currently at a V6 server, you might want to delay the conversion until
you are at a V7 server.

The reason for this is to avoid having to run the conversion twice:
if you do the conversion at V6, you later still need to convert to the V7
tablespace allocation.
Verify V7.1 Tablespaces
To verify your server is using V7.1 tablespace allocation, you can use
the following query again
db2 "select substr(TABSCHEMA,1,20) as schema , substr(TABNAME,1,20) as table, TBSPACEID,
substr(TBSPACE,1,20) as tablespace, substr(index_tbspace,1,20) as indexspace from syscat.tables where
tabschema='TSMDB1' and TBSPACEID>10 order by 3"

SCHEMA TABLE TBSPACEID TABLESPACE INDEXSPACE

-------------------- -------------------- --------- -------------------- --------------------
TSMDB1 ARCHIVE_OBJECTS 12 ARCHOBJDATASPACE ARCHOBJIDXSPACE
TSMDB1 BACKUP_OBJECTS 14 BACKOBJDATASPACE BACKOBJIDXSPACE
TSMDB1 BF_AGGREGATED_BITFIL 16 BFABFDATASPACE BFABFIDXSPACE
TSMDB1 BF_BITFILE_EXTENTS 18 BFBFEXTDATASPACE BFBFEXTIDXSPACE

If you get the above result, either the server was installed at V7.1 or
tablespace conversion was completed.
TSM Tablespace Conversion with V7.1.5

OS DB before DB after Duration Memory Disks

Extract: 1:22 hours
AIX 315GB 205GB Insert: 9:26 hours 64GB 300GB 15k
Runstats: 24 min.
Extract: 0:55 hours
250GB 130GB Insert: 3:35 hours 64GB 300GB 15k
Runstats: 15 min.
Total: 5 hours
Windows 500GB 170GB 64GB NA
Extract: 1:04 hours
Linux 382GB 213GB Insert: 3:58 hours 32GB SSD
Runstats: 43 min.
TSM Database space reduction after Conversion
Additional Considerations
If you were using file device dedup enabled storage pools and you
plan to move to container storage pools vie the

CONVERT STGpool

command, you might want to verify if there is still unused space

allocated to the BF_ tables which is no longer used.

Technote: Clean up file device dedup related tables after moving to

container pools - https://ibm.biz/Bdsie3
Need assistance?

If assistance with the tablespace conversion procedure is requested you can send
an email to

mailto:STG.LabServices@de.ibm.com

There you can request a client tailored service that takes into account the size of
the environment and the expected efforts.
Additional Information:

Find details about the database, reorg and conversion in the most current version of
the reorg technote: https://ibm.biz/BdHxHF

Access to the scripts:

To request access to the scripts open a PMR to document your request. The directory for
worldwide contacts can be found here: https://ibm.biz/BdHxHj
Questions ?!?
Thanks to Matt Anglin, Colin Dawson, Robert
Guthrie, Urs Moser

Thank you!

Norbert Pott
Urs Moser