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

Teradata Vantage™- データベースの管理

Product
Advanced SQL Engine
Teradata Database
Release Number
17.10
Published
2021年7月
Language
日本語
Last Update
2021-09-23
dita:mapPath
ja-JP/upb1600054424724.ditamap
dita:ditavalPath
ja-JP/wrg1590696035526.ditaval
dita:id
B035-1093
Product Category
Software
Teradata Vantage

以下の表はシステムの管理に使用できる一般的なツールの一覧です。この表には、Teradataフィールド エンジニアまたはVantageシステム デベロッパー向けのツールも含まれています。ツールの項目に「Teradata担当者のみ」の記述がある場合は、Teradataサービスからの指示がない限り、ツールを使用しないでください。

各ツールの詳細については、該当のドキュメントを参照してください。推奨される機能(保守、トラブルシューティング、インストールなど)別のユーティリティのリストについては、<Teradata Vantage™ - データベース ユーティリティ、B035-1102>の「ユーティリティのアルファベット順リスト」を参照してください。

トラブルシューティングまたは管理する対象 ツールと説明 参照
管理ワークステーション MPP導入時のAWSコンソールには、ノード、DBWコンソール、BYNETを含む各物理コンポーネントのステータスが表示されます。システム コンソールのSMPに関する多くの機能が表示されます。 AWSマニュアル
AMPとAMPワーカー タスク amploadユーティリティは、使用できない空きAWTが原因となるAMPボトルネックを報告します。

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 Vantage™ - データベース ユーティリティ、B035-1102>の「AMP Load (ampload)」
  • <Teradata Vantage™ - データベース ユーティリティ、B035-1102>の「AWT Monitor (awtmon)」
  • <Teradata Vantage™ - リソース利用マクロおよびテーブル、B035-1099>の「ResUsageSawtテーブル」と「ResUsageSpsテーブル」
データの破損と整合性 チェックサムは、ディスクI/O操作の保全性をチェックします。チェックサムはデータから計算される数値です。指定された一式のデータの場合、データが変更されない限り、チェックサム値は常に同じです。

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

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

<Teradata Vantage™ - データベース ユーティリティ、B035-1102>の「チェックサム フィールド」
  FerretユーティリティのSCANDISKコマンドは、ファイル システムの保全性をチェックします。これにはマスター インデックス、シリンダ インデックス、データ ブロック構造(WALログに関連した構造を含む)が含まれます。

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

SCANDISKを一定時間実行した後にさらにイベントが発生すると、前回オフにしたままになっているSCANDISKを再始動した場合、これまでスキャンしたデータについては最近の障害が原因で発生したエラーが検索されません。このため、保留状態のSCANDISK操作を再始動するのか、操作全体を最初からもう一度実行するのかの判断は注意して行なう必要があります。
<Teradata Vantage™ - データベース ユーティリティ、B035-1102>の「Ferretユーティリティ(ferret)」
ディスク領域 Ferretユーティリティは、フィールド エンジニアおよびTeradataサポート担当者がディスク利用をモニターおよび制御する場合に使用します。

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

このユーティリティは、Vantageエンジニアがルーチンおよび特殊診断を実行するために使用します。
<Teradata Vantage™ - データベース ユーティリティ、B035-1102>の「Ferretユーティリティ(ferret)」
Update DBCユーティリティは、DBaseテーブル内のユーザーDBCのPermSpace、SpoolSpace、およびTempSpaceを再計算します。次にDBase値に基き、Update DBCユーティリティはすべてのデータベースのDBC.DataBaseSpaceのMaxPermSpaceとMaxSpoolSpaceを再計算します。

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

<Teradata Vantage™ - データベース ユーティリティ、B035-1102>の「Update DBC (updatedbc)」
Update Spaceは、特定のデータベースまたはすべてのデータベースの固定領域、一時領域、またはスプール領域を再計算します。 <Teradata Vantage™ - データベース ユーティリティ、B035-1102>の「Update Space (updatespace)」
  FixCurrentSpace SQLストアド プロシージャは、Update Spaceユーティリティであるfixcurrentspaceと同じ関数を実行します。 FixCurrentSpaceプロシージャ
  FixAllocatedSpaceのSQLストアド プロシージャは、グローバル領域アカウント処理を使用するデータベースの動的なニーズベースの割り当てを修復します。 FixAllocatedSpaceプロシージャ
  DBC.DiskSpaceVビューには、ディスク領域の利用状況がAMP別に表示されます。ここには各AMPの一時データとスプール データがデータベースまたはアカウント別に表示されます。このビューを使用して、大量のスプール使用および利用可能な固定領域を追跡します。
障害AMP AMPが停止しているというエラーが表示された場合(例えば、MultiLoadやBTEQジョブから)、Vprocmanagerを使用して致命的なAMPを再起動するか、オフラインの障害AMPを稼働させます。 <Teradata Vantage™ - データベース ユーティリティ、B035-1102>の「Vproc Manager (vprocmanager)」
停止しているテーブル システムは、テーブルのファイル システム構造のいくつかの領域にエラーが発生すると、データ、またはインデックス サブテーブルを停止にマークします。このエラーは、ハードウェアやI/Oの問題が原因の可能性があります。サブテーブルの停止している領域への対処、または修正を行なうには、次のいずれかを実行します。
  • テーブルをDELETE ALL/DROPする文を使用する
  • Table Rebuildユーティリティを使用してテーブルを再構築する
  • バックアップからデータを復元する
  • インデックスを削除してから再作成する
  • フォールバック サブテーブルを削除してから再作成する

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

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

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

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

  • <Teradata Vantage™ - SQLデータ定義言語-構文規則および例、B035-1144>の「ALTER TABLE」
  • <Teradata Vantage™ - データベース ユーティリティ、B035-1102>の「MaxDownRegions」
グローバル パラメータ DBS制御はDBS制御レコードの、調整可能なグローバル パラメータを表示し変更します。 <Teradata Vantage™ - データベース ユーティリティ、B035-1102>の 「DBS制御(dbscontrol)」
ゲートウェイ設定 Gateway Controlユーティリティを使用すると、暗号化の処理方法、ホスト グループに許可されるセッション数、タイムアウト値などのGateway設定を設定できます。

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

このユーティリティは、Vantageエンジニアがルーチンおよび特殊診断を実行するために使用します。
Gateway Globalユーティリティは、LANに接続されたユーザーのセッションをモニターし、制御します。トラフィックのモニター、ネットワーク セッションの制御、ユーザーのセッション状況の表示、および特定セッションのアボートを行なうことができます。
ハングまたはスローダウン このテーブルのトピック「ハングしているセッション」、「AMPとAMPワーカー タスク」および「リソース使用情報」を参照してください。
Resource Check Toolsは、ハングまたはスローダウンを以下のように検出します。
  • mboxchk: 応答時間をモニターします。データベースの応答が遅いか応答がないことが応答時間によって示される場合、mboxchkがTeradataサポート センターのスクリプトを実行してシステム情報を収集し、イベントをログして、Teradata Vital Infrastructure(TVI)に連絡します。
  • nodecheck:ローカルの、ノード レベル リソースのみを表示する。サマリー データを分析のためにsyscheckに供給します。
  • syscheck:システムの速度を低下させる恐れのある輻輳や明らかなハングの徴候がないかモニターして、警告またはアラートのしきい値に達した場合は通知します。

    syscheckrcと呼ばれるテキスト ファイルは各ノード上にあります。これを設定して、しきい値を下回ったリソースを検出し、報告することができます。

    リソース チェック ツールは、/usr/pde/binディレクトリにあります。

マニュアル(Man)ページまたはpdehelpのmboxchk、nodecheck、syscheck
大きなテーブルへのロード より大きなテーブルへのバッチINSERT/SELECTリクエストの速度を加速させるには、トランザクションの日付によってテーブルをパーティション化します。これを行なうと挿入がテーブル全体ではなくパーティション内のデータ ブロックにグループ化されます。これによりI/Oの回数が減ります。

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

ロックの競合または保留されたロック ロック競合の原因は複数あります。例えば、保留中のロック、非常に過重なシステム、マシンの容量を超過するほど多数のトランザクション、DSAとの競合などです。

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

ロック競合について
Lock Displayユーティリティには、使用中のすべての実時間ロックが表示されます。これには同時制御のロックも含まれます。ブロックされているトランザクション、およびブロックを行なっているトランザクションを調べることができます。 <Teradata Vantage™ - データベース ユーティリティ、B035-1102>の「Lock Display (lokdisp)」
同じデータベース内で同じユーザーIDを使用して同時ジョブを実行し、オブジェクトを削除または作成している場合には、DBC.AccessRightsに関連するロッキング問題が発生する可能性があります。
以下を実行することにより、DBC.AccessRightsに関連するロッキング問題を減少させることができます。
  • 数個の異なるユーザーIDを使用してジョブを実行し、それらを複数の接続文字列の間に無作為に分散させることにより、2つのユーザーIDの同時実行の発生を減少させる。
  • 関与するユーザーID/データベースIDに関連するDBC.AccessRightsに対して、ハウスキーピングを実行する必要があるかどうかを判断する。
  • データ ディクショナリ テーブルに関する統計を収集する必要があるかどうかを判断します。
特定のアプリケーションにおけるロッキング問題を減少させることに関するTeradataナレッジ アーティクル
DBQLロック ログには、ユーザー指定のしきい値を超えたすべてのロック競合がXML形式でDBQLXMLLOCKTblに記録されます。

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

XMLロック ログ テーブル:DBQLXMLLockTbl
Showlocksユーティリティは、データベースおよびテーブル内にDSA操作により配置されたすべてのアクティブなホスト ユーティリティ(HUT)ロックを特定し、表示します。

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

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

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

  • Teradata® DSAユーザー ガイド、035-3150
  • <Teradata Vantage™ - データベース ユーティリティ、B035-1102>の 「Show Locks (showlocks)」
メモリ(エラー3710が発生するメモリ不足) DBS制御のMaxParseTreeSegsフィールドに対して設定されたデフォルト値を使用することを推奨します。このエラーが発生した場合、まず問合わせの簡略化や不要な結合インデックスの削除を行ないます。この操作を行なってもエラーが続く場合には、MaxParseTreeSegsに設定した値を確認してTeradataサービスに連絡します。
最適値は、使用しているシステムと実行しているリリースおよび修復レベルによって異なります。MaxParseTreeSegsをデフォルトよりも大きい値に設定すると、以前に失敗した3710エラーを実行できる場合がありますが、解析時間が長すぎたり、極端な場合にはTeradataのリセットなどの別の問題が発生する可能性があります。
<Teradata Vantage™ - データベース ユーティリティ、B035-1102>の「MaxParseTreeSegs」
ジョブの優先順位 TASMは、ジョブの種類に応じて、優先順位を割り当てます。高い優先順位の作業は、より頻繁にCPUとI/Oへのアクセスを受け取ります。

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

<Teradata Vantage™ - リソース利用マクロおよびテーブル、B035-1099>の「ResUsageSpsテーブル」

クエリー BEGIN/REPLACE QUERY LOGGING WITH XMLPLANを使用するか、EXPLAIN IN XMLリクエスト修飾子を使用します。

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

Teradata Viewpointを使用して問合わせを管理します。次のようにできます。
  • オブジェクト アクセスまたは問合わせリソース ルールに対して問合わせにフィルタをかける。
  • 同時発生の観点からシステムに要求された問合わせのフローを制御し、必要に応じて遅延させる。
  • システムの例外動作を記録する。
 
リソース使用情報Teradata Vantage™ - データ ディクショナリ リソース利用マクロを使用して、ノードやvprocsの使用が集中しているリソースの情報を入手できます。ボトルネックの調査に役立ちます。 Teradata Vantage™ - リソース利用マクロおよびテーブル、B035-1099
  DBQLビューのDBC.QryLogVは、最もCPUを使っているAMP、最もI/O処理が多いAMP、問合わせの処理時に使用される最大スプール容量などの情報をレポートします。 <Teradata Vantage™ - データ ディクショナリ、B035-1092>の「QryLog[V]」を参照
ハングしているシステム Query Sessionユーティリティを使用して各セッションの状態を判断してから、Lock Displayユーティリティを使用してロック競合を探します。 セッションの問題のトラブルシューティング
複数セッションにログインしている場合のセッション情報 問合わせを行なっているセッションのThread IDまたはJob IDを検索するためには、まず、SELECT SESSIONを実行します。

問合わせがセッション番号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 Vantage™ - データ ディクショナリ、B035-1092>の「SessionInfo[V][X]」
  Query Sessionユーティリティには、ロード ユーティリティと問合わせセッションの状態が表示されます。Parsing、Active、Blocked、Response、などのステイタスや、ストアド プロシージャの処理状況など詳細なステータスが表示されます。 <Teradata Vantage™ - データベース ユーティリティ、B035-1102>の 「Query Session (qrysessn)」
スキュー スキューを検出する方法が多数あります。
  • 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の高い使用率をモニターするアプリケーションを独自に開発するオプションもあります。
  • <Teradata Vantage™ - SQLデータ操作言語、B035-1146>の「EXPLAINリクエスト修飾子」
  • <Teradata Vantage™ - リソース利用マクロおよびテーブル、B035-1099>の「ResUsageSpsテーブル」、「ResUsageSpmaテーブル」、「ResUsageSvprテーブル」および「ResCPUByAMPマクロ」
スローダウン このテーブルのトピック「ハングまたはスローダウン」を参照してください。  
DBCテーブルへの遅い問合わせ サイトで頻繁にDBCテーブルへの問合わせを行なうカスタム アプリケーションやツールを数多く使用している場合、これらのテーブルの統計収集を検討します。 データ ディクショナリ テーブルの統計収集について
領域の超過 ロード ユーティリティやアーカイブからの復元などの領域を大量に消費する操作で、利用可能な固定領域を超える場合は、操作を完了して領域外エラーを回避するように、2つのDBS制御ユーティリティ フィールドを一時的に設定できます。

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

<Teradata Vantage™ - データベース ユーティリティ、B035-1102>の「DBS制御ユーティリティ」のOverflowMaxPermSpace-
PercentageフィールドとOverflowMaxPermSpace-
KByteCountフィールド
また、グローバル領域アカウント処理を使用して、必要に応じてAMPに余分な領域を提供し、領域不足により領域を大量に消費する操作が失敗しないようにします。 グローバル領域のアカウント処理について
スプール領域の枯渇 スプールの使用が制限されるのには、さまざまな理由があります。
  • グローバル領域アカウント処理を使用しない場合は、必要に応じて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の値を比較できます。

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

ストレージへの領域割当て Teradata Virtual Allocator Manager (TVAM) ユーティリティを使用します。

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

Teradataサービスによる指示がない場合はTVAMユーティリティを使用しないでください。
マニュアル ページとオンライン ヘルプ
システム クラッシュまたは障害 Screen DebugおよびScreen Dumpは、システムがクラッシュダンプに何をどのように記録するかを制御します。Teradataでは、すべてのダンプのデフォルト設定は、システム サポート担当またはTeradataサービスで要求された場合にのみ変更するように推奨しています。 <Teradata Vantage™ - データベース ユーティリティ、B035-1102>の「Control GDOエディタ(ctl)」
DBC.Software_Event_LogVはシステム ビューであり、エラーやシステム障害、およびその関連ノード、vproc、パーティション、タスク、機能、ソフトウェアのバージョン、オプションのバックトレース、診断情報などの詳細な情報を表示します。

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

  • Teradata Vantage™ - データ ディクショナリ、B035-1092
  • Teradata Vantage™ - Databaseメッセージ、B035-1096
DULユーティリティは、システムでダンプされたテーブルをテープに保存、または復元します。 <Teradata Vantage™ - データベース ユーティリティ、B035-1102>の「Dump Unload/Loadユーティリティ(dul)」
システム リカバリ Recovery Managerユーティリティは、クラッシュまたはユーザー アボート後のシステム復旧の進捗状況をモニターおよび報告します。同ユーティリティで、トランザクション ロールバックのモニターやロールバックのキャンセルなどが可能です。 <Teradata Vantage™ - データベース ユーティリティ、B035-1102>の 「Recovery Manager (rcvmanager)」
テーブル Table Rebuildユーティリティは、Vantageが自動的に回復できない表を再構築します。AMPの場合、Table Rebuildは以下を再構築できます。
  • テーブルのプライマリまたはフォールバック部分
  • 完全なテーブル(プライマリおよびフォールパック部分)
  • サブテーブルの特定の範囲の行
  • テーブルの破損している領域
  • 破損しているまたは欠落しているテーブル ヘッダー
  • すべてのテーブル
  • すべてのフォールバック テーブル
  • データベース内のすべてのテーブル
  • テーブルを1つずつ順番に、あるいは各データベースの複数のテーブルを並列で
  • <Teradata Vantage™ - データベース ユーティリティ、B035-1102>の「Table Rebuild (rebuild)」
  • 「テーブルの不整合または破損」も参照
テーブルの不整合または破損 CheckTableは、以下をチェックする診断ツールです。
  • テーブルのバージョン、ParentCountとChildCountのデータ、およびパーティション定義の違いなどの、テーブルとディクショナリの不整合
  • プライマリ データ、フォールバック データ、およびストアド プロシージャ テーブルのテーブルの破壊(行や固有値の重複、およびデータの不整合など)
  • テーブル ヘッダー、行ID、セカンダリ インデックス、参照インデックスなどの内部データ構造内の不整合
  • 無効な行ハッシュ値とパーティション番号
CheckTableには、次のようなオプションがあります。
  • データ保全性チェックの4つのレベル(PENDINGOP、ONE、TWO、THREE)。連続する各レベルは追加チェックを実行します。それらのチェックはより完全なので結果的に所要時間が延びます。
  • DOWN ONLYオプションでは、ダウンしたテーブルのみのステータス情報を表示します。

    DOWN ONLYオプションは、PENDINGOPを除くすべてのレベルで機能します。

  • ERROR ONLYオプションを指定すると、CheckTableはスキップされたテーブル、停止しているテーブル、エラーおよび警告のあるテーブルを表示します。この表示によりCheckTableで検出された問題を、すばやく特定し対処できます。
  • OUTPUTコマンドにより、CheckTableの出力をログ ファイルにリダイレクトできます。このコマンドのECHOオプションにより、出力をコンソールとログ ファイルの両方に直接送信できます。

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

<Teradata Vantage™ - データベース ユーティリティ、B035-1102>の「CheckTable (checktable)」
  Table Rebuildユーティリティを使用して、テーブルのプライマリ コピーまたはフォールバック コピーを修正したり、特定の破損した部分のみを修正したりできます。再構築操作がAMPで問題なく完了すると、TableRebuildはテーブル ヘッダーから停止している領域の情報を削除します。ただし、フォールバック サブテーブルに停止している領域が定義されている場合、再構築プロセスはアボートされ、システムはエラーを返します。

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

  • <Teradata Vantage™ - データベース ユーティリティ、B035-1102>の「Table Rebuild (rebuild)」
  • 「テーブルの不整合または破損」も参照
Vproc Vproc Managerユーティリティでは次のことが実行できます。
  • vprocの状態の表示と変更
  • 特定vprocの初期化とブート
  • 特定のvprocに関連するストレージの初期化
  • 再起動を強制的に実行
vprocには以下のようなステータスがあります。
  • FATAL: vproc、またはその関連ストレージは操作可能ではありません。システムは、クラッシュが繰り返している場合、またはデータの整合性が取れない危険がある場合、そのストレージをfatal(致命的)にマークします。複数のクラッシュは、クラッシュ カウントでわかります。また、複数のクラッシュは、データ破壊、不正なSQL、またはソフトウェア バグが繰り返し発生する状態を示します。Teradataサービスに問合わせてください。
  • FATAL**: これは、「fsgwizard」のデータ整合性状況です。Teradataサービスに問合わせてください。
  • OFFLINE: vprocは操作可能ですが、操作者によってオフラインに故意に設定されています。または、例えば、クリークのすべてのAMPがOFFLINEの場合、そのクリークに稼動しているノードがないためにそれらはシステムによってOFFLINEに設定されています。これは通常、システム全体のすべてのノードを再起動したが、各ノードが同時ではなく別々に稼動する場合に生じます。
    OFFLINE vprocのローカル クラッシュは、データベースを再起動する原因になります。
  • UTILITY Catchup (offline catchup): vprocはこれまで停止していました(OFFLINE、FATAL、またはその他の状態)。そのフォールバック データがクラスタの別のvprocに書き込まれていれば、vprocはそのフォールバック データをキャッチアップしながら、稼動状態に戻ります(ただし、オンラインではありません)。
<Teradata Vantage™ - データベース ユーティリティ、B035-1102>の「Vproc Manager (vprocmanager)」
Vprocとストレージ データベース ウィンドウのSupervisor画面からGET CONFIGを入力して、現在のシステム構成を表示します。

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

  • <Teradata Vantage™ - データベース ユーティリティ、B035-1102>の「データベース ウィンドウ(xdbw)」
  • <Teradata Vantage™ - データベース ユーティリティ、B035-1102>の「Vproc Manager (vprocmanager)」
  Query Configurationユーティリティは、ノードで管理されるvproc、またはシステム全体のvprocの状態をレポートします。 <Teradata Vantage™ - データベース ユーティリティ、B035-1102>の「Query Configuration (qryconfig)」
Vproc Manager (vprocmanager)ユーティリティ vprocmanagerにエラーがある場合
# vprocmanager
PDE is not running: Operation not permitted
PDE event 10117 reported when task is not attached 
to PDE or PDE is down. Task should stop on this
error.

非TPAノードからこのユーティリティを実行しようとした可能性があります。vprocmanagerをTPAノード(Vantageソフトウェアを実行するノード)から実行します。

<Teradata Vantage™ - データベース ユーティリティ、B035-1102>の「Vproc Manager (vprocmanager)」