Read up on backups in the administrtion guides - because the answer to some of your questions are it depends on what db2 has been asked to do.
if you do a *full* backup today and another *full* backup tomorrow, tomorrows backup will contain all the data in todays backup plus any added after today's backup.
If you do a full on day 1 and an incremental delta on day 2, then the backup on day 1 contains all data inserted into the database upto the end of the backup (since this is about online backups - you will have to rollforward through logs and in this statement, I mean backup and logs together) and the backup on day 2 contains all data from the end of backup on day 1 to the end of backup on day 2.
Then there are 2 kinds of incremental backups - delta incremental and cumulative incremental.
So in the second scenario, on day 3 you could either have a delta or a cumulative - if you have a delta, that backup will contain data from the end of backup on day 2 to the end of backup on day 3, whereas if you have a cumulative, it will have data from the end of backup on day 1 to the end of backup of day 3.
Archive logs are required to successfully recover from an online backup. So in order to enable online backups, logretain must be set to yes - you may or may not use userexits. If you issue a list history backup statement you will see that the archive logs associated with the backup are identified in the information returned - to answer your question, db2 will apply the correct set of logs associated with the backups.
Let us restrict this discussion to full online backups.
Upon further reading, I get the following impression. Please let me know if you disagree:
One can do multiple online backups without doing any roll-forward in between. Each time an online backup is done, the corresponding log files are closed and archived. So, one can do online backups A, B, and C in that chronological order. Then, at any time one can do, either full recovery, or at least to the time that backup was made. For example, one could do either full recovery from backup B or recover upto the point in time B was backed up.
If this is true, I like the online backups even more!
If any updates to database are made between the START and END of online backup, it is caught by LOGs. In this case, when you restore, DB is in rollforward pending state. You HAVE to rollforward to a ZULU(GMT) time. Oracle allows you to rollforward to a local time. Local ,GMT time difference is always indicated in dBforums; so it should not be a problem. Also, you have to restore inactive logs to the appropriate place. If you can find a window, where you can force off everybody, then you are better off taking offline backups. By tuning backup parameters, you can narrow the backup window.
One way to determine the minimum point in time to rollforward to is to give the database an improbable date in the past like a year ago - the database returns with the exact minimum point in time. Rollforward must always be run at the catalog node.