You should develop your methods in protected mode, which is the default when you create a new method. Protected and secure modes are states in which each instance of a method runs in a separate process. This is done to protect the system from many common programming errors such as non-valid pointers, corrupted stacks, and illegal computations such as divide-by-zero errors that would otherwise crash the database, produce problems with memory leakage, or cause other potentially damaging results.
The difference between a protected mode server and a secure mode server is that a protected mode server process runs under the predefined OS user tdatuser, while a secure server process runs under the OS user specified by the UDF in its EXTERNAL SECURITY clause. The two processes are otherwise identical.
These problems all cause the database to crash if they occur in unprotected mode. Methods can also cause the database to crash in protected and secure modes if they corrupt the shared data areas between the database and the protected or secure mode method.
- Testing all methods that are in development.
- Running any methods that cause the OS to consume system resources.
This includes anything that causes the OS to allocate system context, including open files, pipes, semaphores, tokens, threads (processes), and so on.
If a method does not perform operations that cause the OS to consume system resources, then you should change its protection mode to EXECUTE NOT PROTECTED (see ALTER METHOD) after it has met your qualification standards for production use.
If a method does perform operations that cause the OS to consume system resources, then you should always run it in protected mode, even after it has been thoroughly debugged and meets all your production-level quality standards.
The following table summarizes this information for production-ready methods:
| IF a method … | THEN you should run it in this mode … |
|---|---|
| does not cause the OS to consume system resources | unprotected. |
| performs operations that cause the OS to consume system resources |
|
The best practice is to develop and test your methods on a non-production test system. You should run any newly created method several hundred times, both to ensure that it does not crash the system and to determine any performance issues that could be avoided by alternate method design and better coding techniques.
You can use the cufconfig utility (see Teradata Vantage™ - Database Utilities, B035-1102 and Teradata Vantage™ - SQL External Routine Programming, B035-1147) to expand the number of protected or secure mode servers from the default value of 2 per AMP or PE to a maximum of 20 per AMP or PE vproc. The minimum is 0.
Protected mode servers consume disk resources as follows:
In unprotected mode, a method is called directly by Vantage rather than running as a separate process. You should only alter a new method that does not require the OS to allocate system context to run in unprotected mode after you have thoroughly tested and evaluated its robustness and performance impact. Once the newly created CPU-operations-only method has passed your quality measures and is ready to be put into production use, you should alter it to run in unprotected mode.