On Thursday 13 August 2015 14:10:16 you wrote:
> Just went from v6.3.5.100 to v7.1.1.300. The procedure went smoothly,
> but so far I'm not impressed with the client backup - slow to start, slow
> to run. I'd hate to think that the only solution for the performance is a
> bit of sleight of hand to reconstruct the tablespace.
>
> Database is only ~350G with ~360 million objects.
>
> Just not sure if I'm going to stay at v7.
IBM support was not really helpful. There conclusion was that we have a
performance problem because they can see that the process was accessing the
DB2, so it was not hanging. So it has to be a performance issue.

The advice: use some script to convert the TSM 6 data to TSM 7 format. This
will reorganize the data internally. It should give us an extra performance
boost and up to 30% reduction in database size.
But this is all at own risk and you need a DB2 guru to understand the scripts.
Remember: 'you don't need any DB2 knowledge'.  Yeah, right....

In the meantime, I restored the database (850 GB) on a standby server.
This server has nothing else to do. Storage is FlashSystem 840 behind SVC.

Expire inventory hangs, but delete filespace gives an error after a few hours.
I also found out that the filespace I can not delete was not mentioned during
expiration.  I renamed the filespace some weeks ago hoping that that will fix
the issue. But the new name is not appearing in the activity log during
expiration. In stead, the original name is appearing. So it looks like the
rename did something (q filespace, q occ, etc is showing the new name), but
also messed up something else!

So I updated my call and I hope that IBM support will believe me that we don't
have a performance issue, but an inconsistency in the database!


Stef