Is it ok to use one fenced id for multiple instances or should we create one fenced id per instance? This is for 9.1 on AIX

Sharing is normal procedure.

What are the advantages/disadvantages of using one fenced id?

I'm not into fenced stuff... so I asked another person this question and here is the response:

"I would think its common to have one fenced id for all your instances.. but in terms of advantages the one i can think of is that its easier to maintain.. since its only one user.. the purpose of the id is for security.. so that udf/sp code is running under a specific id, and that id can be monitored.. if its better to have a separate fenced id for each instance then that's really up to the user.. that way you would know which instance is using a certain sp/udf, and can control that for each instance.. if you use one general fenced id, then it would be hard to detect which instance is using it at a certain time."

The fenced user id exists for routines that are being created to run in fenced mode (outside of the DB2 address space). Very few people write such fenced routines.

• All SQL SP's and UDF's are "not fenced" (they run inside DB2 address space).
• C/C++ routines can be fenced or not fenced, at user option
• Java routines are always fenced.

Since almost all DB2 customers create SQL routines, the fenced id is rarely ever used. Therefore it can be shared among instances.

Some routines that are shipped with DB2 are written in C and are fenced (such as the administrative stored procedures), but since they are already created the fenced user id is not used.

Running a routine in fenced mode means it will be slower than if it ran in "not fenced" mode, but the advantage of fenced mode is that if there is a bug or memory addressing error in the routine, it will not crash DB2.