I have a database(TESTDB) of size 350GB, eventhough i am running online incremental backup for "TESTDB" databse its taking 4 Hours of time but other databases of the same size are completing within half an hour,and there is no daily updates on "TESTDB" database.
A common reason for this symptom is the lack of separate tablespaces to store LONG data. Your bitmap image shows very few tablespaces, suggesting shared tablespaces.
Find out if any populated tables in your application schema(s) have colums of type lob, clob, blob , long-varchar etc.
If you find that such tables exist , it's best to create new dedicated large tablespaces specifically to store long data, and use admin_move_table for each impacted table to split the data, index and long data into separate tablespaces per table.
Sometimes daily housekeeping (inplace reorgs etc) causes shared tablespaces (which hold tables that include long/lob data) to be entirely backed up by incrementals. By splitting out long data into separate nonshared dedicated tablespaces, this reduces the incremental-backup size+duration.
You can also ask db2 to give you details of what's in the incremental backup images, in terms of which tablespaces, and how much of each etc.
You can also check if the backup image includes logs, and discover how much time is spent retrieving any already archived logs from tsm to be sent back to tsm in the backup-image (especially if the TSM server is a shared resource coping with large numbers of other tsm-nodes). This timing will be in the db2diag.log during the incremental backup.
Also check the tsm client log file in $DSMI_LOG in case there are any unusual symptoms there.