Teradataの実行計画について少しずつ整理していきます。 今回は大量データの結合の実行計画について。 こんなクエリは、どういう実行計画になっていればOKだろうか。 select * from t /* 1000万件のトランザクション */ inner join m /* マスタ */ on m.c1=t…

こんなSQLでパフォーマンスが出ない場合、 SELECT * FROM t1 WHERE c1 NOT IN ( SELECT c1 FROM t2 )not inで比較してる列＝t1.c1, t2.c1 にnot null制約が付いているか確認してみるといい。 もしもc1にnullがあり得ないにもかかわらず、not null制約が抜け…

Teradataは、Primary Index(PI)を結合カラムにしたときに結合が最速になる、とマニュアルに書いてある。 以下はこの性質を使ってパフォーマンス改善した事例。 夜間バッチの時間短縮のため、時間のかかっているジョブをチェックしてみると、こんな結合条件の…

Teradataで3000万件ぐらいのテーブルをただ全件引いてみると、 select * from t /* 3000万件 */しばらくだんまりになった後で、猛然と結果が返ってくる。 このだんまりの時間に何をしているのかexplainで調べてみると、 3) We do an all-AMPs RETRIEVE step …

Teradataで3本以上のテーブルを結合する場合、必ず中間結果のスプールへの(つまりディスクへの)書き出しが発生する。 例えばa, b, cの3本を結合するなら、aとbの結合結果をスプールに書いて、次にスプールとcを結合する。 b, cが件数の非常に少ないテーブル…

Teradataはいわゆるshared-nothingアーキテクチャを採用していて、1つのテーブルのデータは、AMPと呼ばれる数十台の仮想マシンに分散して格納される。 Teradataは各レコードのキーすなわちPrimary Index(=PI)をハッシュ関数に食わせて、出てきた値からそのレ…

Teradataでは、readロックがwriteロックを排他する。 つまり、あるテーブルの読み取りのみ行うトランザクションAを実行中に、そのテーブルを更新するトランザクションBを開始すると、更新トランザクションBは、Aがreadロックを解放するまで待ちになる。 ここ…

けっこう大きなWebサイトの構成立案に弊社が参加していて、バックエンドのDBの選定などがウチ担当になっている。 高速なDBが必要ということで、営業サイドはTeradataを推す案を作っている。 高速なDB -> じゃあTeradataで、という感じなのだが、アプリの実装…

Teradataで、あるテーブルに対して複数行insertするジョブを並行して走らせたところ、デッドロックしてしまった。 Teradataの場合、insertのデフォルトのロックはテーブルロックだと思っていたのだがこれが間違いで、実は行ハッシュロックというのが掛けられ…