デフォルトでは、UDFは保護モードで実行するように作成されます。保護モードおよびセキュア モードは、UDFの各インスタンスを別個のプロセスで実行する状態です。保護モード サーバーとセキュア モード サーバーの違いは、保護モード サーバー プロセスが事前定義OSユーザーtdatuserの下で実行されるのに対し、セキュア サーバー プロセスはUDFのEXTERNAL SECURITY句で指定されるOSユーザーの下で実行されるという点です。この点を除けばどちらのプロセスも同じです。
これにより、データベースのクラッシュ、メモリ リークによる問題、他の潜在的な障害の原因となる無効なポインタ、破損したスタック、ゼロ除算エラーなどの不正な計算をはじめとする多くの一般的なプログラミング エラーからシステムを保護できます。
これらの問題はすべて、非保護モードで生じるとデータベースのクラッシュの原因となります。UDFは、データベースと保護モードUDFとの間の共有データ領域を破壊した場合にも、保護モードでデータベースがクラッシュする原因になります。
- 開発中のすべてのUDFのテスト。
- Java UDFの実行。
Java UDFは常に保護モードで実行する必要があります。このため、Java UDFは同等のCまたはC++関数より実行速度が低下します。
- OSでシステム リソースを消費するUDFの実行。これには、OSによるシステム コンテキストの割振りを引き起こすものすべて、たとえば、オープン ファイル、パイプ、セマフォー、トークン、スレッド(プロセス)などが含まれます。
OSシステム呼び出しを行なわない、実働の準備が整ったCまたはC++関数では、保護モードを使用ない。保護モードは、システムに追加の処理負荷を課すので、パフォーマンスが低下する場合が多いからです。一方、非保護モードのUDFは、そのクエリーのステップですでに使用されているAMPワーカー タスクのコンテキストで実行されます。CまたはC++ UDFを保護モードで実行すると、実行速度は低下します。
UDFを非実働のテスト システムで開発およびテストすることが最善です。新規に作成したUDFは数百回実行して、システムがクラッシュしないことを確認すると共に、関数の設計を変更したりコーディング技法を改善することで回避できるパフォーマンス上の問題を判別してください。貧弱な設計のUDFは、システム パフォーマンスを大きく低下させることがあります。
テーブルのカーディナリティはUDFパフォーマンスの重要な要素なので、非実働システム上の小さなテーブルに対して実行されるテストで測定されるパフォーマンスのレベルは、実働データベース内の大きなテーブルに対して実行される場合と異なることがあります。
cufconfigユーティリティを使用すると、保護モードのサーバー数をAMPまたはPE vprocにつきデフォルト値の2から最大値の20に拡張できます。詳細については、<Teradata Vantage™ - データベース ユーティリティ、B035-1102>および<Teradata Vantage™- SQL外部ルーチン プログラミング、B035-1147>を参照してください。最小値は0です。
保護モードのサーバーで消費される、CおよびC++関数用のディスク リソースは、次の式によって計算されます。
非保護モードでは、UDFは別個のプロセスで実行されるのではなく、データベースによって直接呼び出されます。OSにシステム コンテキストの割り振りを要求しない新規のCまたはC++関数は、十分にテストして強固さとパフォーマンス上の影響とを評価してから、非保護モードで実行するように変更してください。新規に作成したCPU操作専用のCまたはC++ UDFが品質尺度に適合して、実働で使用する準備が整った後に、このUDFを変更して非保護モードで実行するようにします。
UDF用のJavaサーバーごとに、約30 MBのスワップ領域用のメモリが必要になります。各ノードには、そのようなJavaサーバーが2つ存在できます。非セキュア モードのJava UDFのためのJava UDFマルチスレッド サーバーは、最小でもさらに30 MBのメモリを使用します(必要量は、ユーザーのJARのサイズに応じて大きくなることがあります)。そのため、すべてのサーバー フレーバーが使用されている場合、各ノードには約100 MBのスワップ領域が必要になります。