SCREEN - Advanced SQL Engine - Teradata Database

SCREENコマンドは、PDE Control GDOからのPDE構成情報の画面を表示します。この情報の一部は、variable = settingおよびWRITEコマンドを使用して変更できます。

構文

{ SCREEN | SC } [ DBS | DEBUG | RSS | VERSION ]

画面名を入力せずにscreenコマンドだけを入力すると、現在の画面(最近表示した画面)が再表示されます。

構文要素

DBS

障害時におけるデータベース ソフトウェアの対応方法を制御するパラメータを表示します。

DBS画面には、以下の制御フィールドがあります:

設定	説明
Minimum Node Action(最小ノード アクション)	クリーク内のノード数が[Minimum Nodes Per Clique(クリークあたり最小ノード数)]フィールドの値より少なくなった場合に実行する処理を指定する。 Clique Downはクリークが開始されず、クリークに関連するvprocはOFFLINEとマークされます。これは、デフォルトです。 DBS Downは、データベースが開始されません。すべてのvprocはOFFLINEとマークされます。
Minimum Nodes Per Clique(クリークあたり最小ノード数)	クリークが動作するのに必要なノード数を指定する。(アクティブでないホット スタンバイ ノードは考慮されません)。データベースの開始時に、クリークにあるノード数がこの数より少ない場合は、Minimum Node Action (最小ノード アクション)設定で指定されている処理が実施されます。 Minimum Nodes Per Clique(クリークあたり最小ノード数)は、すべてのノードが正しく実行されているクリークには影響しません。これには、「単一ノード クリーク」(AMPなしのチャネル ノードなど)も含まれます。これらのクリークに対しては、[Minimum Nodes Per Clique(クリークあたり最小ノード数)]設定に関係なく、[Minimum Node Action(最小ノード アクション)]に指定されている処理は実施されません。 この値を変更した場合、データベースが再始動するまで変更内容は反映されません。 データベースの始動時に、クリークのvproc数、ノード数、および使用可能なメモリ サイズに基づいて、各クリークに必要な最小ノード数が決定されます。システムにサイズが異なるクリークが含まれている場合は、各クリークの最小ノード要件を決定し、そのうちの最大の値をシステムのすべてのクリークに対する最小ノード要件とみなします。 Minimum Nodes Per Clique(クリークあたり最小ノード数)がシステムで決定された最小値よりも小さい値に手動で設定されている場合、手動で設定された値はシステム値で置き換えられ、その処理がシステムログに記録されます。 Minimum Nodes Per Clique(クリークあたり最小ノード数)がシステムで決定された値よりも大きい値に手動で設定されている場合、手動で設定された値が優先されます。 Minimum Nodes Per Clique(クリークあたり最小ノード数)がいずれかのクリークのノードの総数よりも大きい値に手動で設定されている場合、そのクリークのすべてのノードが、使用されるクリークで完全に機能する必要があります。 Minimum Nodes Per Clique(クリークあたり最小ノード数)の値の選択には、パフォーマンスとシステムの可用性の間のトレードオフが伴います。クリーク内の1つ以上のノードに障害が発生した場合、そのノードに割り当てられていたAMPは、クリーク内の残りのノードに移行します。一部のノードが他のノードよりvprocを多く処理する場合、システム パフォーマンスが低下する可能性があります。 Minimum Nodes Per Clique(クリークあたり最小ノード数)の値を設定すると、ここからは、部分的に無効になったクリークを完全に利用不可能とみなした方がシステムにとって効率的、というポイントを定義でき、Teradataのフォールバック ロジックで問題に対応することができます。フォールバックでシステムを実行する場合、一部の機能が制限されるため、この設定の適切な値を選択するときには注意が必要です。
FSG Cache Percent(FSGキャッシュ パーセント)	データベース ファイル セグメント キャッシュに使用可能なメモリの割合を指定します。使用可能なメモリとは、ユーティリティとVantageプログラムの実行に必要なメモリ以外のメモリです。 この値を変更した場合、データベースが再始動するまで変更内容は反映されません。 値をゼロに設定すると、FSGキャッシュ パーセントがTeradataのデフォルト(システム構成によって異なる場合がある)にリセットされます。この設定を無効にすることはできません。
TIM FSG Cache Percent(TIM FSGキャッシュ パーセント)	FSGキャッシュの割合としてホット シリンダ キャッシュのサイズを指定する。 このフィールドが表示されるのは、Teradata Intelligent Memory機能をサポートしているプラットフォームだけです。
Clique Failure(クリーク障害時の処理)	クリークのダウン時の処理を指定する。 Clique Downは、ダウンしたクリークを除いてデータベースが始動を試みる。これがデフォルトです。 DBS Downは、クリークがダウンしている場合、データベースが始動しません。
Cylinder Read(シリンダ読み取り)	1つのシリンダ上のデータ ブロックの大部分を最小限の回数のI/O操作で読み取ることにより、全テーブル スキャン操作を効率的に実行できる。 1つのセクターは、アドレス可能なディスク記憶装置の最小単位です。Teradataファイル システムでは、論理シリンダを構成するために固定数のセクターがグループ化されます。各シリンダには、いくつかのデータ ブロックが含まれています。データ ブロックは、単一のデータベース テーブルの行を格納し、シリンダ内の連続したいくつかのセクターにまたがります。単一のデータ ブロックは、Teradataファイル システムI/Oの最小単位です。読み取るデータ ブロックすべてで、ディスクI/O操作が発生します。 単一のシリンダ上のデータ ブロックの大部分で、通常、単一のテーブルの行を格納します。シリンダ読み取りを使用すると、ファイル システムでは1回のI/Oで1つのシリンダから複数のデータ ブロックを読み取ることができます。完全なテーブルをスキャンする必要があるデータベース操作の場合、これは、このテーブルのすべてのデータ ブロックに対して別々のI/Oを実行するよりも効率的なデータの読み取り方法です。 Onは、シリンダ読み取りが有効になります。システムでは、各データ ブロックを読み取るためにI/O操作を別々に使用するのではなく、最小限の回数のI/O操作で1つのシリンダ上の1つのテーブルのデータ ブロックをすべて読み取ります。 Offは、シリンダ読み取りが無効になります。データ ブロックは、個別に読み取られます。ファイル システムでは、読み取るデータ ブロックごとに一度、I/O操作を実行します。 LogOnlyは、シリンダ読み取りがWALログのスキャンのみに使用されます。
Restart After DAPowerFail(DAPowerFail後の再始動)	ディスク アレイのAC電源障害後にデータベースを再始動するかどうかを選択できます。 Onは、ディスク アレイのAC電源障害後にデータベースを再始動する。これがデフォルトです。 Offは、ディスク アレイのAC電源障害後にデータベースが再始動されません。
Cylinder Read Ageing Threshold(シリンダ読み取りエージングしきい値)	シリンダ読み取りでロードされるセグメントに使用されるFSGキャッシュの最大量(MB)を指定する。値0はTeradataのデフォルトを表わし、大きいシリンダを使用するシステムでは96 MB、小さいシリンダを使用するシステムでは16 MBです。
Maximum Fatal AMPs(FATAL AMPの最大数)	データベースが再始動しなくなるFATAL AMPの最大数を指定する。 デフォルト値は0で、この場合、FATAL AMPが存在する場合でもデータベースは再始動が可能です。これは主に、フォールバック保護を備えたシステム向けです。フォールバック保護のないシステムの場合でも、FATAL AMP上の行にアクセスする問合わせでなければ、AMPオフライン時に完了できる場合もあります。 重要なテーブルのあるサイトでフォールバック保護を利用しない場合、この値を1に設定することで、FATAL AMPが発生した問題が解決するまで、データベースの再始動を阻止できます。FATAL AMPでの実行状態におけるその他の保護としては、この値が1に設定されている時に、Minimum Node ActionおよびClique Failureを DBS-DOWNに設定してください。

DEBUG

PDEとデータベースの内部デバッグに使用されます。

Teradataサポート センター担当者から明示的に指示されないかぎり、デバッグ値は変更しないでください。

Debug(デバッグ)画面には、以下の制御フィールドがあります:

設定	説明
Start DBS(DBSの始動)	PDE始動時にデータベースを自動的に始動するかどうかを設定する。 Offは、PDE始動時にデータベースを自動的に始動しません。 Onは、PDE始動時にデータベースを自動的に始動する。これがデフォルトです。
Break Stop(中断時停止)	致命的なエラーが発生した場合にデータベースを自動的に再始動するか、またはシステム デバッガが接続されるまで停止するかを制御する。 Offは、ダンプ実行後にデータベースを自動的に再始動する。これがデフォルトです。 Onは、データベースが停止し、システム デバッガが接続されて問題が対話形式で診断できるようになるまで待機する。
Start With Logons(ログオン時の始動)	ログオンを使用可能にするかどうかを制御する。 次の値が適用されます。 Noneは、ユーザーによるシステムへのログオンが認められません。 Allは、すべてのユーザーがシステムにログオンできます。 DBCは、新規DBCユーザーのみシステムにログオンできます。 LocalDBCは、ローカルDBCユーザーのみがシステムにログオンできることを意味します。 この設定を変更した場合、変更内容は次回にdatabaseを再始動した後に反映されます。Start With Logons(ログオン時の始動)コマンドは、データベース ウィンドウのSupervisor(スーパーバイザー)ウィンドウから発行しても同じ効果が得られます。ただし、その場合にはデータベースを再始動する必要はありません。詳細は、データベース ウィンドウ(xdbw)を参照してください。
Start With Debug(デバッグ時の始動)	システム デバッガーの接続が完了するまでのデータベース ソフトウェアの始動を設定する。 Offは、データベースを通常どおり始動する。これがデフォルトです。 Onは、システム デバッガが接続され、操作の続行で使用されるまで、データベースは実行されません。
Save Dumps（ダンプの保存）	データベース ダンプがデータベースにロードされるかどうかを指定する。 次の値が適用されます。 Offは、データベース ダンプがデータベースにロードされません。これは、デフォルトです。 Onは、データベース ダンプがデータベースにロードされます。
Snapshot Crash(スナップショット クラッシュ)	スナップショット ダンプ後にデータベースの実行を続けるかどうかを指定する。 Offは、スナップショット ダンプ後もデータベースが実行を継続する。これがデフォルトです。 Onは、スナップショット ダンプに続いて、データベース全体が再始動されます。[Break Stop (中断時停止)]もOnの場合、システムはデバッグのために停止する。
Maximum Dumps	ノードごとに適用され、データベース ダンプに対してのみ有効。保存されるクラッシュ ダンプの最大数を制御する。値を-1に指定した場合、システムはダンプ ディレクトリのあるディスクに格納できる数のダンプを保存する。 デフォルトは5です。このフィールドを0に設定すると、データベース ダンプが無効になります。
Start PrgTraces(PrgTracesの始動)	PrgTracesをファイルに保存するかどうかを指定する。 Offは、PrgTracesがファイルに保存されません。これは、デフォルトです。 Onは、PrgTracesがファイルに保存されます。
Restart Dump Type(ダンプ タイプの再始動)	データベースの致命的なエラーで実行するメモリ ダンプの種類を指定します。種類は以下の2つです。 システム すべてのシステム ノード上で、すべてのPDEプロセスをダンプする。 Selective: エラーを引き起こした問題の解析と関わりがありそうなプロセスのみをダンプする。 Selectiveダンプは小さいため、より短時間で収集できます。このため、データベースを早期に再始動できます。
UDF Debugging(UDFデバッグ)	Vantageでデバッグ セッションを許可する。Vantage内で実行されるUDFおよび外部ストアド プロシージャをデバッグするには、Teradataから提供されるデバッガを使用する必要があります。 Teradataでは、C/C++およびJava向けのコマンドライン デバッガおよびEclipse (Studio)プラグイン デバッガも提供しています。これらのデバッガの詳細については、<Teradata Vantage™- SQL外部ルーチン プログラミング、B035-1147>、C/C++ UDF用Teradata Debugger、およびJava UDFのTeradata Debuggerを参照してください。 デフォルトはOff。

RSS

Teradataのリソース使用状況(ResUsage)統計は、リソース サンプリング サブシステム(RSS)によって収集されます。これらの統計は、データベース内の専用のテーブルに記録されます。

RSS画面では、ResUsageデータ ロギングの頻度を指定できます。

RSS画面には、以下の制御フィールドがあります:

設定	説明
Node Logging Rate(ノード情報ロギング頻度)	統計のデータベースへの書き込み間隔(秒単位)。 デフォルトは600です。
RSS Table Logging Enable (RSSテーブル ロギングの使用可能化)	各種のResUsageテーブルに対するロギングを有効化するかどうかを制御する。 デフォルトでロギングが有効になっているのはSPMAテーブルだけである。
RSS Summary Mode Enable (RSSサマリー モードの使用可能化)	いずれかのResUsageテーブルについてロギングを有効化すると、ロギング期間ごとに複数行のリソース使用状況データが書き込まれる。要約モードを使用すると、RSSではロギング エンティティごとに1行格納する代わりに、各ノードでの種類ごとに1行の要約を格納するため、ロギング期間ごとに収集されるデータの量が減少する。 例えば、通常のロギングがSCPUテーブルについて有効化されている場合、ロギング期間ごとに、すべてのCPUに関する統計を格納した別個の行が書き込まれる。サマリー モードを有効化すると、ノードのCPU数には関係なく、各ノードについて1行のみが書き込まれる。その単一行には、ノードのすべてのCPUに関するサマリー データが含まれている。 同様に、通常のロギングがSVPRテーブルについて有効化されている場合、個々のすべてのvprocについて別個の行が書き込まれる。このテーブルについてサマリー モードを有効化すると、vprocの種類(AMP、PE、およびその他)ごとに1行が書き込まれる。 テーブルに対してRSSサマリー モードを有効にするには、RSS Table Loggingも有効化する必要があります。

• ResUsageレポートを実行するためには、ロギング頻度を選択し、ロギングのための適切なテーブルを有効にしておく必要があります。
• 英数字識別子のないフィールドは変更しないでください。
• RSSは、毎時0分にログ期間を時計に合わせます。したがって、3600秒(1時間)をこれらの値で割り切ることができなければなりません。RSSのロギングの頻度として有効な値は以下のとおりです: 0, 1, 2, 3, 4, 5, 6, 8, 9, 10, 12, 15, 16, 18, 20, 24, 25, 30, 36, 40, 45, 48, 50, 60, 72, 75, 80, 90, 100, 120, 144, 150, 180, 200, 225, 240, 300, 360, 400, 450, 600, 720, 900, 1200, 1800, 3600。
• ResUsageテーブルの詳細および各テーブルに格納される情報のタイプについては、<Teradata Vantage™ - リソース利用マクロおよびテーブル、B035-1099>を参照してください。

VERSION

Versions(バージョン)画面には、実行中のPDEおよびデータベース システム ソフトウェアのバージョン番号が表示されます。 この画面の入力フィールドでは、システムで実行されるソフトウェアの別のバージョンを指定することができますが、その値は次回システムを再始動したときにシステムに反映されます。

Versions(バージョン)画面には、以下の制御フィールドがあります:

設定	説明
Running PDE	現在実行中のTeradata並列データベース拡張機能のバージョン
Running DBS	現在実行中のデータベースのバージョン
Running TGTW	現在実行中のTeradata Gatewayソフトウェアのバージョン
Running TCHN	現在実行中のTeradata Channelソフトウェアのバージョン
Running RSG	現在実行中のTeradata Relay Services Gatewayソフトウェアのバージョン。
Running TDGSS	現在実行中のTeradata Generic Security Servicesソフトウェアのバージョン
Running PDEGPL	現在実行中のTeradata並列データベース拡張機能のGNU General Public Licenseのバージョン
Desired PDE	このフィールドをインストール済みのPDEバージョンに変更すると、次回データベースを再始動したときにそのバージョンが実行される。
Desired DBS	このフィールドをインストール済みのデータベース バージョンに変更すると、次回データベースを再始動したときにそのバージョンが実行される。
Desired TGTW	このフィールドをインストール済みのTGTWバージョンに変更すると、次回データベースを再始動したときにそのバージョンが実行される。
Desired TCHN	このフィールドをインストール済みのTCHNバージョンに変更すると、次回データベースを再始動したときにそのバージョンが実行される。
Desired RSG	このフィールドをインストール済みのRSGバージョンに変更すると、次回データベースを再始動したときにそのバージョンが実行される。
Desired TDGSS	このフィールドをインストール済みのTDGSSバージョンに変更すると、次回データベースを再始動したときにそのバージョンが実行される。
Desired PDEGPL	次回データベースを再始動したときに実行されるインストール済みのPDEGPLバージョンを示す。 Desired PDEが異なるバージョンに設定されると、CTLツールはDesired PDEGPLをそれと同じバージョンに自動的に設定します。

使用上の注意

• 各画面には関連する制御フィールドのグループが表示されます。変更可能なフィールドの値を変更するには、variable = settingコマンドを使用し、完全なフィールド名、または画面出力でフィールドの横に表示される英数字識別子を使用してそのフィールドを識別します。英数字識別子のないフィールドは変更しないでください。
• フィールドの値を変更するスクリプトでは、英数字識別子ではなく、完全な変数名を使用する必要があります。