At the start of processing a backup job, DSA gets a Host Utility (HUT) Read lock on every object in the job plan. If the job plan includes a database, DSA puts a Read HUT on the whole database. If the job plan includes an object, DSA puts a Read HUT lock on the object. DSA requires all the HUT Read locks for every object in the job plan to be acquired before the objects are actually archived, so there is a consistent sync point and data integrity can be guaranteed when the data is restored.
In addition, the backup will put access locks on several DBC tables to get the object definitions. The locks are held for the duration of the DUMP command and are released as soon as possible. Once the command is DUMP complete, the locks are released so they are not held while the dictionary data is being written or during the rest of the dictionary phase. Some of the tables that are locked include TVM, DBASE, UDFINFO, TEXTTBL, IDCOL, DEPENDENCY, JAR_JAR_USAGE, ROUTINE_JAR_USAGE, ERRORTBLS, JARS, REFERENCEDTBLS, REFERENCINGTBLS, CONSTRAINTNAMES, TRIGGERSTBL, UIF_INFO, SERVERTBLOPINFO, DBCASSOCIATION, INDEXES, TVFIELDS, SERVERINFO, and TABLECONSTRAINTS. There is also a read lock placed on the ARCHIVELOGGINGOBJSTBL. These are table level access locks.
The HUT Read lock is released as soon as the object is completely archived. For objects without a table header that are archived at the object level, the lock is released at the end of the dictionary phase. For tables that are archived at the object level, the lock is released as soon as the object is completely archived. For database level locks, the lock is released as soon as all the objects in the database have been completely archived.
The last database or object processed for the archive job will require the lock for the entire job.