Command "extend dbspace" rebalances extents inefficiently

[krusz]

Hi,
I got some problem with "extend dbspace reclaimstorage=yes" command. I add new disks for DB2 but rebalancing and reclaiming space process moves extents to new disk in very inefficient way. The tablespace extents are not distributed equally among all disks. It looks like this:
Location Total Space of File System Used Space on File System (MB) Free Space(MB)
(MB)
------------------------------ ------------------------------ ------------------------------ ------------------------------
/tsm/oprtsm/db 959,543.97 747,253.86 212,290.12
/tsm/oprtsm/db02 511,931.18 450,431.86 61,499.32
/tsm/oprtsm/db03 511,931.18 450,431.41 61,499.77
/tsm/oprtsm/db04 511,931.18 449,966.97 61,964.21
/tsm/oprtsm/db05 503,962.43 475,515.48 28,446.95
/tsm/oprtsm/db06 503,962.43 163,629.46 340,332.97
/tsm/oprtsm/db07 503,962.43 163,629.45 340,332.98
/tsm/oprtsm/db08 503,962.43 163,629.81 340,332.62

/dev/mapper/tsmvg-tsmdblv 938G 725G 208G 78% /tsm/oprtsm/db
/dev/mapper/tsm02vg-tsmdb02lv 500G 440G 61G 88% /tsm/oprtsm/db02
/dev/mapper/tsm03vg-tsmdb03lv 500G 440G 61G 88% /tsm/oprtsm/db03
/dev/mapper/tsm04vg-tsmdb04lv 500G 440G 61G 88% /tsm/oprtsm/db04
/dev/mapper/tsm05vg-tsmdb05lv 493G 440G 28G 95% /tsm/oprtsm/db05
/dev/mapper/tsm06vg-tsmdb06lv 493G 158G 333G 33% /tsm/oprtsm/db06
/dev/mapper/tsm07vg-tsmdb07lv 493G 158G 333G 33% /tsm/oprtsm/db07
/dev/mapper/tsm08vg-tsmdb08lv 493G 158G 333G 33% /tsm/oprtsm/db08

Do you have any idea what I should do to utilize the space on all disks in the same way?

 

[marclant]

It takes a while to rebalance. Plus, it's not possible to evenly rebalance when the filesystems are all of different sizes.

Your best bet to rebalance and to obtain optimal performance from your DB is to do the following:
1. backup the DB
2. recarve your storage to have 8 equal size LUNs mounted to the 8 filesystems
3. restore the DB

Ideally, if you are going to go through that effort of recarving, you are better off to create 12 LUNs mounted to 12 filesystems. That way, the next time you need to extend the database, you can just extend all 12 filesystems by the same amount and won't need a rebalance.

Off topic, extents are unique to container pools. What DB2 is moving is database pages.

 

[krusz]

marclant, thanks for the reply. I know that it takes time to rebalance, in my situation it took 6 hour. Almost all of the disks are the same size, only one of them is different size. I do not plan to recover the DB at the moment, but what I want to do is to connect 4 additional disks, in order to have 12 used by the TSM DB.
Thanks for the explanations.

 

[krusz]

Is it make sense to expand all the disks to the same size (1 TB) and make rebalancing manually at the moment (instead of adding next 4 500 GB disks)?

 

[marclant]

s it make sense to expand all the disks to the same size (1 TB)

No, this will make things worse. You want ALL filesystems to be the same size.

 

[krusz]

Exactly. I mean that I will expand all filesystems to the same size (1TB) the DB pages are placed on . After this operation I will do:
db2 alter tablespace tablespace_name rebalance
db2 alter tablespace tablespace_name reduce max
Is it correct way of thinkig or should I add new disks (filesystems) as you mentioned above?

 

[marclant]

Oh sorry, I misunderstood. If I understand correctly, you would like to extend all current 8 filesystems to 1 TB, for a total of 8 TB.

No, I would not recommend that. If you look at large Blueprint (link in my signature), for databases larger than 4 TB, it's recommended to have 12 DB directories/LUNs of equal size. DB2 does some parallelism of the workload across all the database directories, when the database gets larger, DB2 benefits from more database directories.