To protect the system from new external routines that have not passed your quality metrics, the default run mode for all external routines is EXECUTE PROTECTED. If the default specification for CREATE/REPLACE FUNCTION were EXECUTE NOT PROTECTED, then an error in the created function could stop the system.
Protected mode is a database state that traps on memory address violations, corrupted data structures, and illegal computations, such as divide-by-zero, to make sure they do not stop the system. Protected mode does not detect or protect against CPU and memory loops or operating system I/Os such as opening external files to read from or write to them.
This run mode isolates the data the external routine may access as a separate process, or "platform," in its local work space. If a memory violation or other system error occurs, the error is localized to the routine and the transaction running it, not the entire database (see General Usage Guidelines: CREATE FUNCTION and REPLACE FUNCTION (External Form)).
Because this isolation also makes the C or C++ routine run slower, change its protection mode to unprotected after it has passed your quality metrics for being put into production use. You change the run mode for the routine with ALTER FUNCTION, specifying EXECUTE NOT PROTECTED.
Both Java and row-level security constraint UDFs must run in protected mode and cannot be altered to run in unprotected mode (see Special Considerations for Java UDFs).
Do not make this change for any UDF that makes OS system calls. Any such UDF must run in protected mode. You need not recompile or relink the external routine after changing its protection mode.
Typically, the DBA must only specify direct run mode (EXECUTE NOT PROTECTED) for a function that performs CPU-only operations after it has been debugged. Only the DBA must be granted the privileges to alter it to run in unprotected mode. Do not run external routines that cause the OS to consume system resources in unprotected mode. This includes anything that causes the OS to allocate system context, including open files, pipes, semaphores, tokens, threads (processes), and so on.
The following table summarizes how the UDF protection mode options must be used:
| Situation | Run Mode |
|---|---|
| You are developing and debugging function. | EXECUTE PROTECTED |
| Function is written in Java. | EXECUTE PROTECTED You cannot alter a Java function to run in unprotected mode. |
| Function uses operating system resource that requires tracking by operating system. For example: opening files, pipes, semaphores, tokens, threads, processes. | EXECUTE PROTECTED Running such a function in unprotected mode can interfere with proper database operation. |
| Function uses no operating system resources and is debugged. | EXECUTE NOT PROTECTED. Running a UDF in unprotected mode speeds up its processing significantly. |