The test case provided loads 100,000 rows into a table, and the
table has an insert trigger that does a for each row execute
procedure and that procedure is defined as a java udr. With the
default setting of IFX_EXTEND_ROLE=1 in the $ONCONFIG, it took
~30 minutes to load the 100,000 rows.
If the table is then truncated, and IFX_EXTEND_ROLE is set 0,
and the program is re-run to insert the 100,000 rows, that load
completes in ~ 30 seconds.
If you get stack traces from the thread as is runs on the jvp
oninit process you will tend to see stacks like this:
#13 in getgrent () from /lib64/libc.so.6
#14 in atdbsal ()
#15 in sqisrolegranted ()
#16 in sq_user_has_extend ()
#17 in udrlm_java_execute_internal ()
#18 in udrlm_java_execute ()
#19 in udrlm_exec_routine ()
#20 in udr_execute ()
#21 in exroutine ()
#22 in execproc ()
#23 in aud_execproc ()
#24 in excommand ()
#25 in dotrigs ()
#26 in ferafttrig ()
#27 in addone ()
#28 in insone_next ()
#29 in doinsert ()
#30 in excommand ()
#31 in sq_execute ()
#32 in sqmain ()
So it appears the server is spending a lot of time calling the
OS library getgrent().
The description of IFX_EXTEND_ROLE in the $ONCONFIG says that it
would be doing extra checking when trying to register external
routines, so it's a bit unclear why it would impact performance
when just trying to execute the routines. |
