トラブルシューティングおよび管理のためのツール - Advanced SQL Engine - Teradata Database

AWT Monitor (awtmon)ユーティリティは、アクティブな(使用中の) AMPワーカー タスクの数をすばやく表示して「hot AMPs」を決定するため、パフォーマンスの問題をトラブルシューティングできます。

awtmonは“puma -c”コマンドのフロントエンド ツールで、AWT使用中カウント情報をサマリー形式で出力します。

デフォルトでは、awtmonはローカル ノードのAWT使用中カウントを表示します。-sオプションを使用して、システム規模の情報を出力し、ホットAMPをシステム全体のノードに配置できます。ホットAMPが識別されたら、pclまたはpshを使用してこれらのホット ノードでawtmonを実行します。

ResUsageSawtテーブルを使用して、作業タイプごとにAMPワーカー タスクの使用中の数を確認し、AMPがフロー制御の状態に入るタイミングを判別することもできます。

どのワークロードがI/Oスキューをもたらしているかを判別するには、ResUsageSpsテーブルを使用し、それからDBQLを使用して特定の問合わせを識別します。

チェックサムの計算にはシステム リソースが必要になりシステムのパフォーマンスに影響する可能性があるので、大半のプラットフォームではシステム全体でのチェックサム実行はデフォルトで無効にされています。ディスクの破損が疑われる場合は、Teradataカスタマー サポートに連絡してください。

テーブル、ハッシュ インデックス、または結合インデックスのチェックサムを有効にするには、CREATE TABLE、ALTER TABLE、CREATE JOIN INDEX、CREATE HASH INDEX文のCHECKSUMオプションを使用します。

先に停止されていたSCANDISK操作は、Perlスクリプトを使用して再始動できます。

同ユーティリティのコマンドにより、システムはシリンダ上の空きセクターの結合、ディスクで一定割合の空き容量を確保するための内容の再構成、パッキングに適したテーブルの報告、およびディスク シリンダの利用状況と空きシリンダの表示を行ないます。

Update DBCは、DBaseテーブルまたはDataBaseSpaceテーブルの不整合を訂正するためにのみ使います。この不整合は、システム障害でも非常にまれなタイプの結果として生じることがあります。

• テーブルをDELETE ALL/DROPする文を使用する
• Table Rebuildユーティリティを使用してテーブルを再構築する
• バックアップからデータを復元する
• インデックスを削除してから再作成する
• フォールバック サブテーブルを削除してから再作成する

停止しているテーブルを修正してから、ALTER TABLE…RESET DOWN文を使って停止しているテーブルをリセットします。

ハードウェア エラーの場合、フォールバック テーブルを再構築して、フォールバック サブテーブルから行のコピー、プライマリ サブテーブルの停止している領域の行の修正、およびその逆を実行できます。停止しているテーブルを以前のバックアップから再構築、または復元する場合、さまざまなサブテーブルの停止ステータス フラグがリセットされ、それらにある行もフォールバック コピーからマークのないデータ ブロックやシリンダに移動します。

テーブルを停止にマークするまでに失敗するAMPあたりの領域の数を変更するには、DBS制御のMaxDownRegionsフィールドを使用します。

詳細については、このテーブルの「テーブル」を参照してください。

Gateway Controlユーティリティには、接続のタイムアウト時間、外部認証の設定、システムのデフォルトを使用するか、顧客が構成後または新しいホスト グループやゲートウェイvprocなどを追加後に設定可能なデフォルトを使用するかなどを選択できるオプションがあります。

DBQLユーティリティ ジョブ ログ テーブル、DBC.DBQLUtilityTblを使用して、ユーティリティ ジョブのパフォーマンスをトラブルシューティングすることもできます。

セッションを実行する順序や時間帯に注意して計画すれば、ロックの競合を避けることができます。EXPLAINを使用します。リクエストの実行では、EXCLUSIVEロックを使用することやピーク時間外に処理を行なう方法を検討してください。

Viewpointロック ビューアー ポートレットを使用してDBQLロック ログにアクセスできます。あるいは、システム テーブルDBC.DBQLXMLLOCKTblまたはビューDBC.QrylockLogXMLVに対する問合わせを実行することもできます。

HUTロックは、アプリケーション処理を妨げる可能性があり、そのユーティリティの処理が完了した後に、通常は解放されます。

ロックがアプリケーション処理を妨げる場合、RELEASE LOCK文を呼び出すことによって、それらのロックを除去できます。これは、ARCユーティリティを介して、またはSQL文として使用できます。

start showlocksコマンドを使用して、DB Window Supervisor画面からShowlocksを開始できます。

ResUsageSpsテーブルを使用して、ワークロードごとにCPUがどれほど消費されているかを把握します。また、このテーブルを使用して、処理日のデータベース アクティビティのパターンも把握できます。

あるいは、BEGIN/REPLACE QUERY LOGGINGのSTEPINFOオプションを使用して、最もリソースを使用しているステップを判別したり、CPU、I/O、行数の予想と実際の量に大きな差があるかどうかを判別したりします。

問合わせがセッション番号nを返すため、その番号を次の問合わせで使用します。

sel logonsource
from sessioninfovx
where sessionno =  n;

*** Query completed. One row found. One column
returned.
*** Total elapsed time was 1 second.

LogonSource
-------------------------------------------------------
(TCP/IP) 09AB 127.0.0.1 DBC    8804  USER  BTEQ  01 LSS

これはどのクライアント プロセス/Thread IDがどのセッションに属しているかを判断するのに役立ちます。特に役立つのは、複数のセッションにログオンしているため、どのThread IDがどのセッションに属しているか見つける必要がある場合です。

• Teradata Viewpointを使って、CPUを最も多く使っているユーザーを判断します。通常、I/Oアクセスと比較してCPUの使用率が高いユーザーを検出すれば、問題のある問合わせを検出できます。
• EXPLAINテキストを確認して、問合わせに使われているステップの数とオペレーションのタイプを判断します。記述に問題がある問合わせには、積結合などが見つかることがあります。そのような問合わせはアボートし、さらに詳しく調査して問合わせを修正します。
• ノード レベルのスキューを識別するには、ResUsageSpmaテーブルを使用して、最大CPU使用量をすべてのノードで消費されるCPUの平均と比較します。ResUsage Spmaテーブルに示される並列性効率が100%に到達していない場合、不均衡の原因を調べます。
• AMPレベルのスキューを見つける方法には、いくつかのオプションがあります。ResCPUByAMPマクロを使用して、AMPレベルのCPUスキューを見つけます。ResUsageSpvrテーブルを確認して、vproc間のリソース使用量を比較します。また、ResUsageSpsテーブルのリクエスト数のフィールドを確認して、1つのノードのワークロードが他のノードよりも多くのリクエストをサポートしていないかを確かめ、AMPにドリル ダウンします。さらに、ResUsageSpsテーブルを使用して、キューの待機数やサービス時間を調べ、ワークロードや割り当てグループごとに渋滞している問合わせを見つけます。
• リクエスト レベルでスキューを見つけるために、DBQLogTblのMaxAMPCPUTimeフィールドとMinAMPCPUフィールドを比較できます。DBQLではユーザー ロギングが不完全になることがよくあるため、ResUsageのテーブルとマクロの方がより正確な情報を提供する場合があります。
• PM/APIを使用して、CPUの高い使用率をモニターするアプリケーションを独自に開発するオプションもあります。

この設定は、テーブルの挿入など、領域アカウンティングのすべての操作とすべてのインスタンスに適用されるので、これらのフィールドを非ゼロ値に設定するのは、一時的に限ることが推奨されます。

• グローバル領域アカウント処理を使用しない場合は、必要に応じてAMPに余分な領域を確保できます。
• 間違って記述された問合わせにより、スプール領域が過度に使用される場合があります。Teradata Viewpoint を使用して実行前に必ず問合わせを確認してください。EXPLAIN で使用されるスプール量を確認するようにすると、システムが不正な問合わせによりオーバーロードするのを防ぐことができます。
• 古い統計情報は、不正な問合わせの原因になります。最適化ルーチンは、使用する統計情報がシステムを正確に反映していない場合、適切な問合わせ計画とは異なる計画を計算する場合があります。また最適化ルーチンは、収集された統計に基いてシステムで要求されるスプールの量、または不要なスプールの量を決定します。収集した統計情報は定期的に更新します。
• OLAP統計機能を使っていてスプールを使い果たす場合は、問合わせの構文を確認してください。例えば、PARTITION BY句を使っている場合に、パーティション列の多数の同じ値が同じAMPにハッシュされると、この結果スプール不足エラーが発生します。行が多くのAMPに分散されるように列を選択してください。
• 偏りの少ないデータ。データ分散が少ないということは、1つのAMPで大部分のデータを処理しているということです。スプール領域はAMPの数で分割されるため、1つのAMPのスプール領域の上限に達すると、他のAMPに未使用のスプール領域がある場合にも、問合わせが失敗します。
• AMPの偏りを生じる、間違って選択したPI。スプール領域はAMPの数で分割されるため、1つのAMPのスプール領域の上限に達すると、他のAMPに未使用のスプール領域がある場合にも、問合わせが失敗します。
• スプール領域の再割り当てを行なわずにノードまたはAMPを追加すると、さらに多くのAMPの中でスプールが展開されます。
• プロファイルで定義されているスプール領域の制限は、ユーザー設定に優先されます。プロファイルの制限がユーザーに定義された制限よりも小さいかどうかチェックします。DBC.DiskSpace.VのMaxProfileSpoolとMaxSpoolの値を比較できます。

ユーザーのスプール領域を制限すると、予測される不正な問合わせの影響(積結合など)を減らすことができます。妥当な制限を設定すれば、ユーザーには不正な問合わせがシステムを停止させる前にスプール不足のメッセージが表示されます。また、スプールを問題のある問合わせに追加すると、問合わせの実行時間が長くなり、問題のある問合わせは完了しません。

システム上のシリンダのマッピング表示やシリンダの強制移行ができます。

ビューのEvent_Tagフィールドは、エラー メッセージ番号をレポートします。

• テーブルのプライマリまたはフォールバック部分
• 完全なテーブル(プライマリおよびフォールパック部分)
• サブテーブルの特定の範囲の行
• テーブルの破損している領域
• 破損しているまたは欠落しているテーブル ヘッダー
• すべてのテーブル
• すべてのフォールバック テーブル
• データベース内のすべてのテーブル
• テーブルを1つずつ順番に、あるいは各データベースの複数のテーブルを並列で

• テーブルのバージョン、ParentCountとChildCountのデータ、およびパーティション定義の違いなどの、テーブルとディクショナリの不整合
• プライマリ データ、フォールバック データ、およびストアド プロシージャ テーブルのテーブルの破壊(行や固有値の重複、およびデータの不整合など)
• テーブル ヘッダー、行ID、セカンダリ インデックス、参照インデックスなどの内部データ構造内の不整合
• 無効な行ハッシュ値とパーティション番号

CHECKTABLEBはCheckTableの非インタラクティブ バッチ モード版であり、cnsrunユーティリティを使用して実行できます。CHECKTABLEBはスクリプトでの実行という点を除き、CheckTableと全く同じです。

フォールバックの一部が停止しているテーブルは再構築できません。ストアド プロシージャ、UDF、およびUDMSは再構築できますが、再構築するテーブルに定義されている結合インデックス、またはハッシュ インデックスは再構築できません。

• vprocの状態の表示と変更
• 特定vprocの初期化とブート
• 特定のvprocに関連するストレージの初期化
• 再起動を強制的に実行

vprocおよびディスクを管理するためには、Vproc Managerユーティリティを使用します。