В общем случае для DB2, и не только - декларативность (один запрос) гораздо предпочтительней процедурности (курсор-цикл-постые изменения), так как дает гораздо больше возможностей оптимизатору. В DB2 при выполнении запроса он с начала собирается в единый текст со всеми view и UDF на SQL, затем оптимизатор пытается его оптимально переформулировать (в зависимости от уровня оптимизации).
Процедура лишает бедного оптимизатора его работы :)

I_love_MSDNFavn, т.е. если на клиенте формируется один большой запрос на изменение данных таблицы, или 10 маленьких, которые отправляются поочередно, и изменяют по 1 записи - то в данном случае лучше одним большим (т.е. 1 вариант)? Или вы имели ввиду процедуру сохраненную?Писал, скорее, для идеального случая - локального коннекта. На удаленном клиенте все хуже многократно, т.к. удаленный курсор дольше держит блокировки, промежуточные запросы по сети болтаются и т.д.
Для SP надо еще учесть, что она компилируется один раз, и потом (по умолчанию) планы обновятся только при явном REBIND, что не есть минус, но надо учитывать при администрировании. План же динамического запроса будет переделан по необходимости.
В любом случае, как на клиенте, так и в процедуре, один большой запрос (типа MERGE) обычно выгоднее - все-таки в гордости IBM по поводу оптимизатора DB2 есть рациональное зерно :)

askfinderВ частности мне известно, что в случае использования CLI именно так и происходит. А вот что происходит при вызове SQL-хранимой процедуры из внешнего клиента по JDBC (Java или EJB на J2EE-сервере)?
Т.е. можно ли считать, что вне зависимости от типа SP (SQL PL, C или JAVA) и варианта ее вызова план строится (по дефолту) только однажды. Если Да, то каким образом я могу обновить план SP (интересует именно SQL PL процедура) в моем случае?С CLI происходит не так - это динамический SQL, он компилируется "на лету", хотя для отдельных частых запросов и можно вручную создать статический package. Т.е. если динамический запрос ("запрос из строки") вызывается даже из SP - он выполняется динамичеки, т.к. текст запроса на момент компиляции package не известен.
BIND/REBINDприменимы к статическому SQL - embedded SQL в C, SQLJ в Java. Для SP на SQL-PL - целиком за исключением динамических запросов.
Для процедуры или приложения на C и Java со static SQL создается связанный с ним отдельный package. Для него можно явно сказать REBIND, указав при этом время формирования планов - при компиляции (по умолчанию), при первом запуске или каждый раз.
Для SP на SQL-PL package создается всегда - он и есть результат компиляции процедуры. Вместо команды BIND - собственно создание SP, вместо REBIND - сис. процедура SYSPROC.REBIND_ROUTINE_PACKAGE
При этом планы доступа формируются сразу.
Кстати, UDF на SQL-PL вообще не компилируются, а хранятся в исходном тексте, который подставляется in-line прямо в текст вызывающего запроса.