TSM 7.1.7 - dsmserv extend dbspace

[jamesmacd40]

Hi all

experienced an issue with extend dbspace on a tsm 7.1.7 server. DB was running out of space (220GB) so a 100GB directory was added by using the dsmserv extend dbspace dbdirectory

THe process completed, but the following

ANR9999D_3831306406 ReportSQLDiagInfo(dbieval.c:1591) Thread<87>: Missing sqlState=01690, sqlCode=2094 from table.
Returning rc = 9994.
ANR9999D Thread<87> issued message 9999 from:
ANR9999D Thread<87> 000007FEF0F38027 OutDiagToCons()+167
ANR9999D Thread<87> 000007FEF0F318F2 outDiagfExt()+112
ANR9999D Thread<87> 000007FEF0BDA570 ReportSQLDiagInfo()+2a0
ANR9999D Thread<87> 000007FEF0BD9402 DbiEvalSQLOutcomeX()+502
ANR9999D Thread<87> 000007FEF0BD2D3B DbiExecuteOnConn()+1fb
ANR9999D Thread<87> 000007FEF0BD2A4C dbiExecuteStmt()+dc
ANR9999D Thread<87> 000007FEF0BF9C66 RebalanceOneTbls()+196
ANR9999D Thread<87> 000007FEF0BF9732 TblsReclaimThread()+192
ANR9999D Thread<87> 000007FEF04D7881 startThread()+141
ANR9999D Thread<87> 000007FEF03B4F7F beginthreadex()+107
ANR9999D Thread<87> 000007FEF03B5126 endthreadex()+192
ANR9999D Thread<87> 00000000773059CD BaseThreadInitThunk()+d
ANR9999D Thread<87> 000000007756383D RtlUserThreadStart()+1d
ANR0162W Supplemental database diagnostic information: 1:01690:2094 ([IBM][CLI Driver][DB2/NT64] SQL2094W The
rebalance of table space "IDXSPACE1" either did not add or drop containers, or there was insufficient disk space to
create all of the containers. Reason code: "2". SQLSTATE=01690


So reading up on that, it looks like the 100GB additional space may not have been enough as the db container is looking like it is bigger than 100GB.

When i looked at this paragraph, i took it to mean that i could get away with just assigning new dbspace half the size of the existing

For example, assume that your table space has four directories over two existing storage paths (two directories per path), and you add another storage path to the database. When data is redistributed for the table space, two new directories of the same size as the existing directories are created on the new storage path. If your table space has a size of approximately 100 GB, then you need 50 GB of free space on the new storage path for redistribution to be successful. After redistribution is complete and space is reclaimed, the total used space is still the same amount of 100 GB, until you begin adding more data.

I am concerned about this error and whether or not if TSM is halted, if it will come back up. THe other option i think i have is to backup the database completely, halt TSM, reconfigure the drive TSM uses for the database and restore the DB to the new location that is now comprised of the old space and new space into one big space...


thoughts or suggestions?

 

[marclant]

How many DB LUNS/directories do you have now?
What size are they?
If the ones you have now are even size, you can add 1 or many more that are the same size as the original one.

I like your idea of backup and restore the DB. I would not restore it one large space though. I'd create 4 LUNs/directories, and use that. DB2 benefits by having multiple directories, it can do more parallel I/O when there are more directories. Each directory must be it's own LUN/filesystem though.

 

[jamesmacd40]

Original was about 260GB directory (only 1 directory) new directory was 100GB. this environment is on windows 2008, old and no new storage to put behind it. so the DB is sitting on internal drives in a mirror config.

We only had 100GB available to extend the DB, which i thought would work here, but the error indicates a big no.

I think the plan will need to backup the db, destroy the underlying disk config, create 4 new luns, 4 new drive letters, (or create a small lun, mount the 4 larger ones into directories) create directories and restore the DB back to those....