А не намного меньше,
например, примерно как размер всех архивных логов с момента последнего полного бэкапа?

Даже если логов накопилось всего сотня мегабайт, то инкрементальный и дельта получаются как полный, т.е. около сотни гигабайт.

IBM упоминает как возможные причины такого поведения бэкапа блобы и dirty pages в буферах.

У других админов по словам начальника получаются маленькие дельты и быстро.
Так что блобы исключаю.

Про dirty pages не уверен, как с ними бороться? деактивировать базу?

Что еще может помешать создавать нормальный небольшой инкрементальный бэкап соизмеримый с накопленными архивными логами с момента последнего полного бэкапа?

аналогичная проблема:
https://jazz.net/forum/questions/125614/size-of-db2-incremental-backup-seems-to-be-too-big-for-no-activity-ccm-database

Mark BarinsteinПосле взятия полного реорганизация таблиц не делается ли случайно?

нет конечно, сегодня уже после реорганизации был сделан полный бэкап,

попробовал перекрыть соединения к DB2 файрволом, дал команду на сброс буферов - сообщило, что и так нет dirty pages, форснул все приложения, деактивировал базу запустил бэкап - та же история (огромная дельта)

обратился в службу техподдержки, они собираются открывать PMR

отправил на mail

Сегодня дождался окончания дельта бэкапа,

бэкап получился ожидаемого относительно малого размера (около 6GB), но команда:

db2 LIST UTILITIES SHOW DETAIL;

Показывала почти полный размер как обычно около 80GB

Получается, дельта бэкап просканировал все 80GB, но записал из них действительно только дельту.
Длительность его выполнения была сравнима с полным бэкапом, т.е. экономии на времени выполнения бэкапа не получилось.