На сегодняшний момент большинство реляционных баз данных занято хранением операционных данных, полученных от OLTP (OnLine Transaction Processing) приложений. Такие приложения предназначены для поддержки текущей деловой активности финансовых, административных и промышленных организаций, где данные, в основном, числовые и символьные.
OLTP-приложения оперируют с критически-важными данными, которые требуют защиты от несанкционированного доступа, от нарушений целостности, от аппаратных и программных сбоев. Типичной является ситуация, когда система должна поддерживать быстрый доступ к данным большого числа пользователей, выполняющих относительно несложные запросы на поиск и обновление данных. Критическим показателем для OLTP является время ожидания выполнения типичных запросов, которое не должно превышать нескольких секунд.
В условиях постоянного роста объема хранимых данных, необходимым требованием к DB2 становится возможность масштабировать систему при увеличении объемов данных, при увеличении потока транзакций и количества пользователей, в первую очередь, путем наращивания аппаратных ресурсов, при сохранении времени отклика системы в допустимых пределах.
До появления реляционных СУБД задачи поддержки OLTP решались с использованием дополнительного программного обеспечения - мониторов транзакций, например CICS. Однако практика внедрения архитектуры клиент-сервер без применения промежуточного монитора транзакций потребовала универсализации сервера баз данных и оснащения его некоторыми свойствами мониторов транзакций для внешнего взаимодействия и повышения производительности.
Наглядными примерами тенденции преобразования многих СУБД и, в частности, DB2 в легкие мониторы транзакций могут служить появившиеся у СУБД функции поддержки хранимых процедур и компонентов для координации изменений в распределенной базе данных.