Amazon Redshift は、パッチ 198 以降、新しい Python UDF の作成をサポートしなくなります。既存の Python UDF は、2026 年 6 月 30 日まで引き続き機能します。詳細については、[ブログ記事](https://aws.amazon.com/blogs/big-data/amazon-redshift-python-user-defined-functions-will-reach-end-of-support-after-june-30-2026/)を参照してください。 # STL\_ALERT\_EVENT\_LOG パフォーマンスの問題を示している可能性のある条件がクエリオプティマイザによって特定された場合にアラートを記録します。クエリパフォーマンスを向上させる機会を特定するには、STL\_ALERT\_EVENT\_LOG ビューを使用します。 複数のセグメントから構成された 1 つのクエリ。各セグメントは 1 つ以上のステップから構成されます。詳細については、「[クエリ処理](c-query-processing.md)」を参照してください。 STL\_ALERT\_EVENT\_LOG はすべてのユーザーに表示されます。スーパーユーザーはすべての行を表示できますが、通常のユーザーは自分のデータのみを表示できます。詳細については、「[システムテーブルとビューのデータの可視性](cm_chap_system-tables.md#c_visibility-of-data)」を参照してください。 **注記** STL\_ALERT\_EVENT\_LOG には、メインのプロビジョニング済みクラスターで実行されるクエリのみが含まれます。同時実行スケーリングクラスターやサーバーレス名前空間で実行されるクエリは含まれていません。メインクラスターと、同時実行スケーリングクラスターやサーバーレス名前空間の両方で実行されるクエリの説明プランにアクセスするには、SYS モニタリングビュー [SYS\_QUERY\_DETAIL](SYS_QUERY_DETAIL.md) を使用することをお勧めします。SYS モニタリングビューのデータは、使いやすく理解しやすいようにフォーマットされます。 ## テーブルの列 | 列名 | データ型 | 説明 | | --- | --- | --- | | userid | integer | エントリを生成したユーザーの ID。 | | query | integer | クエリ ID。クエリ列は、他の各種システムテーブルおよびビューを結合するために使用できます。 | | slice | integer | クエリが実行されていたスライスを識別する番号。 | | segment | integer | クエリセグメントを識別する番号。 | | step | integer | 実行されたクエリステップ。 | | pid | integer | ステートメントとスライスに関連付けられるプロセス ID。複数のスライスで実行される場合、同じクエリに複数の PID がある可能性があります。 | | xid | bigint | ステートメントに関連付けられるトランザクション ID。 | | event | character(1024) | アラートイベントの説明。 | | solution | character(1024) | 推奨される解決策。 | | event\_time | timestamp | UTC で表されたクエリの開始時間。合計時間にはキューイングと実行が含まれます。秒の小数部は 6 桁の精度で表されます。例: 2009-06-12 11:29:19.131358。 | ## 使用に関する注意事項 STL\_ALERT\_EVENT\_LOG を使用してクエリの潜在的な問題を特定し、「[クエリパフォーマンスのチューニング](c-optimizing-query-performance.md)」の説明に従ってデータベース設計を最適化して、クエリを再作成できます。STL\_ALERT\_EVENT\_LOG は以下のアラートを記録します。 + **見つからない統計** 統計が見つかりません。データロードまたは大規模な更新の後で ANALYZE を実行し、COPY 操作で STATUPDATE を使用します。詳細については、「[Amazon Redshift クエリの設計のベストプラクティス](c_designing-queries-best-practices.md)」を参照してください。 + **ネステッドループ** 通常、ネステッドループは直積集合です。クエリを評価して、関与しているすべてのテーブルが効率的に結合されていることを確認します。 + **非常に選択的なフィルター** スキャンされた行に対する返された行の比率が 0.05 未満です。スキャンされる行数は `rows_pre_user_filter` の値であり、返される行数は [STL\_SCAN](r_STL_SCAN.md) システムビューの行の値です。結果セットを決定するために、クエリが著しく大量の行数をスキャンしていることを示します。この問題は、ソートキーが見つからない場合や正しくない場合に起こります。詳細については、「[ソートキー](t_Sorting_data.md)」を参照してください。 + **過剰な数の非実体行** 削除済みだがバキューム未処理としてマークされた比較的多数の行、または挿入済みだがコミットされていない比較的多数の行がスキャンによってスキップされました。詳細については、「[テーブルのバキューム処理](t_Reclaiming_storage_space202.md)」を参照してください。 + **サイズの大きな分散** ハッシュ結合または集計で 100 万を超える行が再分散されました。詳細については、「[クエリ最適化のためのデータのディストリビューション](t_Distributing_data.md)」を参照してください。 + **サイズの大きなブロードキャスト** ハッシュ結合で 100 万を超える行がブロードキャストされました。詳細については、「[クエリ最適化のためのデータのディストリビューション](t_Distributing_data.md)」を参照してください。 + **直列実行** 内部テーブル全体が単一ノードに再分散されたために直列実行を強制する、DS\_DIST\_ALL\_INNER 再分散スタイルがクエリプランで指定されました。詳細については、「[クエリ最適化のためのデータのディストリビューション](t_Distributing_data.md)」を参照してください。 ## サンプルクエリ 次のクエリは、4 つのクエリに関するアラートイベントを表示します。 ``` SELECT query, substring(event,0,25) as event, substring(solution,0,25) as solution, trim(event_time) as event_time from stl_alert_event_log order by query; query | event | solution | event_time -------+-------------------------------+------------------------------+--------------------- 6567 | Missing query planner statist | Run the ANALYZE command | 2014-01-03 18:20:58 7450 | Scanned a large number of del | Run the VACUUM command to rec| 2014-01-03 21:19:31 8406 | Nested Loop Join in the query | Review the join predicates to| 2014-01-04 00:34:22 29512 | Very selective query filter:r | Review the choice of sort key| 2014-01-06 22:00:00 (4 rows) ```