We do refreshes using database tools instead of the UBE as well. The way we handle your concerns is to identify tables that don't exist in PD or have changed is with backup scripts. We are SQL Server, so I don't know the details of DB2, but we use a script that looks at the create and modify dates on the tables in PD and PY. You can usually tell tables that have changed since the majority of the PY tables should have the date from the last refresh which means any dates after that will have changed. We use scripts to copy those tables to a backup/utility/generic database and restore the tables from that database after the refresh.
The biggest hassle with using database refresh is the UDO architectures in 9.1. I haven't tackled that issue since it hasn't been a big complaint for us, but I am concerned about it as we are upgrading to 9.2 where UDO is greatly expanded. It would be great if Oracle provided some type of "admin sweep" in OMW to be able to identify all the UDO objects in PD and demote them down to PY which could be used after a database refresh. Better yet, someone would create a third party tool to do the required moves using database tools.
I just read Hari's response and it sounds to me like I should clarify. When I say database tools I mean restoring backups, not running scripts, to move the data. I take a full backup from the Production database and restore it as the CRP database. I then use scripts to change owners, logins and update stored procedures and functions. It takes some prep time to refresh the scripts to catch new objects that need changed, but the benefits are tremendous. I can do it during the day with no impact on the production system at all and it is very fast.