Db2 – Monitor delete statements on a specific table on DB2 LUW

There are several aspects that you might want to consider.

Firstly, you can assign proper authorities to the target instance owner during the restore automatically by using the DB2_RESTORE_GRANT_ADMIN_AUTHORITIES registry variable. If it's set to ON prior to the restore, the user performing the restore will get those authorities.

Secondly, most of the binding/compiling problems come from the fact that only the object owner, that is, the authorisation ID that created the object in the first place, is given permissions to perform certain operations on it. If you run DDL scripts in production as the instance owner, then this would be the owner ID of all objects after the restore, no matter the DB2_RESTORE_GRANT_ADMIN_AUTHORITIES setting. You could, of course, use the TRANSFER OWNERSHIP statement to change that, but in real life, with tens of thousands of objects in the database, this may not be practical.

To avoid the "secondly" part, in many organisations folks use a special "builder" authorisation ID, separate from the instance owner, to run DDL scripts. This ID will not be given any unnecessary privileges, can be tightly controlled, and, when existing in all environments, should be able to perform all necessary tasks without adding security exposure.

You can only use SQL statements in a trigger. RUNSTATS and REORG are not SQL statements; they are DB2 CLP commands, and only the command line processor understands them. You can try using the system stored procedure ADMIN_CMD() to invoke those utilities, however, 1) it still may not work because of the nature of the utilities and 2) even it does work it would not be a good idea.

There are other problems with your trigger. You cannot use FETCH FIRST in a delete statement, for example. And what is the point of updating statistics just before a REORG?