TSM 5.5. Database backup slowness

[daniel.lestar]

Hi all.

I have a problem with my server. I have a database about 12 million pages large. It is being backed up directly to tape.
When the full database backup runs, the first 10 million or so pages are being saved rather quick (about 10-20 minutes), but the last 1.5-2 million pages take more than 2 hours. This causes the log to fill up to 95%, and the server freezes. I am not sure, what the issue can be, the logpinned command gives no indication, that something is pinning it, so i have no other ideas. I know, the best would be to update to 6.3 or above, but it is not an option at the time.
Do you guys have any ideas, what the issue could be?

Daniel

 

[SniperKing]

Hi,

Is this backup time slow down recently? I guess you may have to check your TSM DB disk layout and disk I/O activity during the DB backup is running.

As an alternative, you may use a file devclass to backup the TSM DB to isolate the problem related to hardware.

 

[daniel.lestar]

Thank you for your reply.
I have checked, there is no underlining hardware issue (or at least there is none to be found)
I see, that the expiration is also real slow, only 1.5 million objects were scanned in about 12 hours.
Migration and session speed is not affected as far as I can see...

 

[rgg]

Hi all.

I have a problem with my server. I have a database about 12 million pages large. It is being backed up directly to tape.
When the full database backup runs, the first 10 million or so pages are being saved rather quick (about 10-20 minutes), but the last 1.5-2 million pages take more than 2 hours. This causes the log to fill up to 95%, and the server freezes. I am not sure, what the issue can be, the logpinned command gives no indication, that something is pinning it, so i have no other ideas. I know, the best would be to update to 6.3 or above, but it is not an option at the time.
Do you guys have any ideas, what the issue could be?

Daniel

The log is probably pinned by the database backup operation.

Have you checked the cache hit ratio? Do you need to change the bufpoolsiz? How big is this database in terms of GB? What type of media is the backup going to? What else is happening (backups, processes?) when the database is being backed up?

 

[daniel.lestar]

Hello.
Yes, you are right, the log is being pinned by the DB backup.
The cache hit ratio is currently at 99.31%. The DB is 113,3 GB, utilized at 40%.
The backup is going to an LTO3 tape. Sessions are running, if needed migration processes.

 

[rgg]

Hello.
Yes, you are right, the log is being pinned by the DB backup.
The cache hit ratio is currently at 99.31%. The DB is 113,3 GB, utilized at 40%.
The backup is going to an LTO3 tape. Sessions are running, if needed migration processes.

So the DB is like 50GB and it takes 2 hours to backup to LTO3 tape. That's pretty darn slow. It's likely either a disk read problem, or a tape write problem.

Why don't you collect some performance instrumentation and see?

 

[SniperKing]

Hi,

For slow expiration rate, it could be a disk problem. You may need you unix/wintel admin to capture the iostat for the TSM db disk to check any underlying disk problem.
Or if you have some spare fast disk which could get hold of your TSM db, move the dbvol to there and see.