TSM DB2 Sizing and Structure Question

[mkbowman]

Hello


I have a p720 server with AIX 6.1 installed. Back end Storage is on a DS4800 behind a SVC. I am going to be using SDDPCM as we currently do that on a p520 server running Aix 5.3.

Our existing production TSM 5.5 Server's database is 150GB (130GB used). I'm not doing a migration as I plan on moving clients over to the TSM 6.2 server in small quantities.

The p720 is a single 8-Core CPU with 32GB Ram (in case we decide on dedup)

My initial thoughts on DB2 sizing are:-

Directories

/opt/tivoli/tsm/db/dbdir001 100GB
/opt/tivoli/tsm/db/dbdir002 100GB
/opt/tivoli/tsm/db/dbdir003 100GB
/opt/tivoli/tsm/db/dbdir004 100GB

Active Log

/opt/tivoli/tsm/log/active 30GB ?

Archive Log

/opt/tivoli/tsm/log/archive 30GB (probably a bit on the low side??) I backup about 300,000 files a day.


dbvg will be the DB2 Dir Volume Group (4 LUNS - 1 hdisks / LUN)
actvg will be the DB2 Active Log Volume Group (1 LUN - 1 hdisk)
archivevg will be the DB2 Archive Log Volume Group (1 LUN - 1 hdisk)

Questions:

1. Is my archive log size going to be too small to cater for two full TSM DB2 backups?
2. Is the active log size overkill for 300 nodes?
3. Should I have more DB2 directories and smaller sizes?

I probably have more questions as I think of them.

Any feedback would be appreciated. Thank you.

 

[Jafco]

Since your storage is behind the svc I'd just make 1 400G disk for the dbvolume. The idea of using four directoriesis that you spread the I/O over several physical disk on your 4800 but the SVC does that for you. Also, there is no harm in making the active log larger than you need so you don't run out of space if you miss a dbbackup over a weekend or something. Mine is 100G

 

[KB]

I agree with Jafco regarding putting the database on one volume. Based on what I am hearing from other customers and corroborated by a DB2 performance white paper, when using stripped disk for the database you want to stick with one database volume. Otherwise you will likely see poorer than expected performance. Another tip is to make the instance home directory a separate filesystem because if the instance home directory runs out of space your DB2 stops.

 

[adsmsuser]

hi!

am i counting correct?

DB:
in tsm 5: 80GB
in tsm 6 -> 80GB*1.5 = 120GB (as recommended) + some growth: 150GB

ARCHIVE LOG:
select sum(num_files) from occupancy -> which returns 108.851.601 objects
when i sum all the files from all backups during 24hours i get 21.820.713, so approximately 1/5th of data is changing per day. wow.
ibm says:
objects/day x 3000 bytes/object x 2 days = 130924278000 bytes ~= 125GB <- WHAT

in TSM5 we have 8 GB redolog ^^.
Utilized up to 55% during 12 Hours. means we should have 32GB in tsm5 to keep 2 days. which is FAR LESS then 125GB!!!!

two things:
- we do a dbbackup eacht 12 hours
- tsm5 does incremental dbbackups if redolog is getting full. tsm6 will do so as well, will it?

so setting 100GB should be more than enough in this environement as well?

thanks

 

[adsmsuser]

found an error

its not 21.820.713 objects, but 741.316
that happens if you miss some "()" in your select statement

^^

 

[GregE]

Based on what I am hearing from other customers and corroborated by a DB2 performance white paper, when using stripped disk for the database you want to stick with one database volume. Otherwise you will likely see poorer than expected performance.

My SAN is XIV (not behind SVC). For the purpose of DB performance, would a single DB volume still be best here too?

 

[KB]

Yes, for XIV, one LUN-LV for the database but still make multiple database containers to force more parallel IO out of DB2. http://ibm.co/Xc3AXg

 

[GregE]

Ken, that is excellent info. Thank you.

 

[MrOdysseus]

Hi GregE,
The most recent whitepaper is saying at a minimum 8 Drives/LUNS paths for a deduplication Database.
]
What did you end up doing?
I'm currently setup with 4 paths, but they were under one Drive letter. I've been debating if I want to break it up over 4 LUNS/Drives. But I'd like to know that the performance increase is going to be worth the effort.


https://www.ibm.com/developerworks/...ptimizing performance for servers and clients