FENCED or NOT FENCED - выполнять в адресном пространстве ядра СУБД или нет
This clause specifies whether the stored procedure is considered "safe" to run in the database manager operating environment's process or address space (NOT FENCED), or not (FENCED).
If a stored procedure is registered as FENCED, the database manager protects its internal resources (for example, data buffers) from access by the procedure. All procedures have the option of running as FENCED or NOT FENCED. In general, a procedure running as FENCED will not perform as well as a similar one running as NOT FENCED.

CAUTION:
Use of NOT FENCED for procedures that have not been adequately checked out can compromise the integrity of DB2. DB2 takes some precautions against many of the common types of inadvertent failures that could occur, but cannot guarantee complete integrity when NOT FENCED stored procedures are used.
Either SYSADM authority, DBADM authority, or a special authority (CREATE_NOT_FENCED) is required to register a stored procedure as NOT FENCED. Only FENCED can be specified for a stored procedure with LANGUAGE OLE or NOT THREADSAFE.

7 LANGUAGE CLR stored procedures cannot be created when 7 specifying the NOT FENCED clause (SQLSTATE 42601).

THREADSAFE or NOT THREADSAFE - запускать отдельно нитью или нет

Specifies whether the procedure is considered safe to run in the same process as other routines (THREADSAFE), or not (NOT THREADSAFE).
If the procedure is defined with LANGUAGE other than OLE:

If the procedure is defined as THREADSAFE, the database manager can invoke the procedure in the same process as other routines. In general, to be threadsafe, a procedure should not use any global or static data areas. Most programming references include a discussion of writing threadsafe routines. Both FENCED and NOT FENCED procedures can be THREADSAFE.
If the procedure is defined as NOT THREADSAFE, the database manager will never invoke the procedure in the same process as another routine.
For FENCED procedures, THREADSAFE is the default if the LANGUAGE is JAVA 7 or CLR . For all other languages, NOT THREADSAFE is the default. If the procedure is defined with LANGUAGE OLE, THREADSAFE may not be specified


В сущности так - если NOT FENCED - процедура работает в адресном пространстве агента, а не ядра. А если - THREADSAFE - до аген запустит еще и дополнительную нить и не будет использовать глобальные и статические данные своего процесса.

Максимум что произойдет - грохнется коннект клиента (FENCED NOT THREADSAFE) или ХП вернет ошибку (FENCED THREADSAFE)

>Сомнительное достоинсто хотя и доступно в Oracle.
>Кроме того есть возможность компилить XП не в P-COD PL/SQL а в NATIVE.

Никто с этим не спорит. Но попробуйте в этом коде поюзать STL или какие-нибудь низкоуровневые функции операционной системы )

>OPTIMIZER_MODE first_rows_n -
чтож, это не ставит ДБ2 ни ниже ни выше Оракла. Так и запишем - в этом месте они одинаковы.

>Что подразумевается под уровнями оптимизации?
http://publib.boulder.ibm.com/infocenter/db2help/topic/com.ibm.db2.udb.doc/admin/r0001007.htm
Почитаете сами?

Yo!>зачем грохаться - в C коде же нет ошибок, просто небольшой мемори лик, т.е. этот агент скушает всю доступную память и ни FENCED ни THREADSAFE ему это не помешают, правильно ?

Ну, если "всю" - память, то это не "небольшой" ) Думаю если небольшой, то сессия закончится раньше, чем все грохнется.

Мой любимый анекдот:
Программер пишет код на ассемблере:
m1: ...
...
jump m1;
jump m1;

Его спрашивают - почему 2 джампа?
Ответ: а вруг первый не сработает?....

[quot Yo
может агент как-то принудительно чистит память после выполнения процедуры?[/quot]
Вроде для threadsafe всякий раз будет запускаться своя нить. Нить выполнилась - ресурсы связанные с ней освободились. Объекты у threadsafe - все в стеке.

[quot Yoа ну да ... догично :) итак до 8.2 это был ежинственный вариант писать сп, а в этом году вышел 8.2 и там уже как у всех есть своя VM для сторед процедур ?[/quot]
Ну до 8.2 было так или как в Оракле с NATIVE.

На вскидку по поводу:
[quot Yo!]Technical Comparison of Oracle9i Database vs. IBM DB2 UDB V8.1: Focus on Performance
http://www.oracle.com/technology/deploy/performance/pdf/CWP_9IVSDB2_PERF.PDF


Indexing capabilities
Oracle: Wide variety of indexing schemes
DB2: Only B-Tree and dynamic bitmap indexes
Конечно это не совсем индексы, но в Оракле этого пока нет:
http://publib.boulder.ibm.com/infocenter/db2help/topic/com.ibm.db2.udb.doc/core/c0009070.htm?resultof=%22%4d%44%43%22%20%22%6d%64%63%22%20

Additional data warehousing capabilities
Oracle: MERGE Multi-table INSERT
DB2: Not supported Not supported
http://publib.boulder.ibm.com/infocenter/db2help/topic/com.ibm.db2.udb.doc/admin/r0010873.htm

Intelligent advisories
Oracle: Index, Summary, Memory, MTTR
DB2: Index advisory only
http://publib.boulder.ibm.com/infocenter/db2help/topic/com.ibm.db2.udb.doc/admin/c0005144.htm

По другим "наездам" тоже можно покапаться и что-нить найти.
Вывод: где-то Оракл впереди, где-то Db2

http://info.star.spb.ru/Oracle/Oracle9i_doc/appdev.901/a88876/adg07iot.htm
Особой (или принципиальной) разницы между Index-Organized таблицами Оракла и кластерными таблицами в других базах (Sybase,MS SQL, DB2) - не вижу.