PolarDB:SQL Explorer

機能

Database Autonomy Service (DAS) は、全リクエストデータとセキュリティ監査を基に、検索、SQL Explorer、セキュリティ監査、トラフィックリプレイとストレステストなどの機能を統合しています。これらの機能は、SQL 文の詳細の取得、さまざまなパフォーマンスの問題のトラブルシューティング、高リスクソースの特定、およびビジネストラフィックのピークに対応するためのクラスター仕様のスケールアップが必要かどうかの確認に役立ちます。

• [検索]機能: SQL ステートメントと、データベース、ステータス、実行時間などの関連情報をクエリおよびエクスポートします。 詳細については、「監査」をご参照ください。

• SQL インサイト 機能は、SQL の健全性を診断し、パフォーマンスの問題をトラブルシューティングし、ビジネス トラフィックを分析します。詳細については、「SQL エクスプローラー」をご参照ください。

  • 「SQL Review」機能：グローバルな SQL 負荷分析を提供します。データベースインスタンス内の疑わしい SQL 文を迅速に特定し、分析して、最適化の提案を得るのに役立ちます。詳細については、「SQL Review」をご参照ください。

  • 「トラフィックリプレイとストレステスト」機能：トラフィックのリプレイとストレステストを実行します。インスタンス仕様のスケールアップが必要かどうかを確認し、ビジネストラフィックのピークに対応するのに役立ちます。詳細については、「トラフィックリプレイとストレステスト」をご参照ください。

  • セキュリティ監査機能は、高リスク SQL、SQL インジェクション、新規アクセス元などのリスクを自動的に識別します。詳細については、「セキュリティ監査」をご参照ください。

  • [トランザクション分析]機能では、指定された期間内に指定されたスレッドのトランザクションタイプ、トランザクション数、およびトランザクション詳細を取得できます。 これにより、トランザクションレベルでデータベースのパフォーマンスを理解、分析、最適化できます。 詳細については、「トランザクション分析」をご参照ください。

  • 「クイックトランザクション分析」機能：分析したい SQL 文を含むトランザクションの最初と最後の文を取得し、トランザクションがコミットされたかロールバックされたかを確認できます。詳細については、「クイックトランザクション分析」をご参照ください。

サポート対象リージョン

SQL Explorer and Audit は、DAS Enterprise Edition を有効にした後にのみ利用できます。各 Enterprise Edition でサポートされるリージョンは異なります。詳細については、「サポートされるデータベースとリージョン」をご参照ください。

影響

SQL Explorer を有効にすると、すべての DQL、DML、および DDL 操作に関する情報が記録されます。データベースカーネルがこの情報を出力するため、システムの CPU 消費量は非常に低くなります。

注意事項

RAM ユーザーとして 検索 機能を使用するには、RAM ユーザーに AliyunPolardbReadOnlyWithSQLLogArchiveAccess 権限を付与する必要があります。詳細については、「RAM ユーザーの作成と管理」をご参照ください。

課金

SQL Explorer and Audit の有効化

1. PolarDB コンソールにログインし、左側のナビゲーションペインでクラスターをクリックします。クラスターがデプロイされているリージョンを選択し、クラスター ID をクリックしてクラスター詳細ページに移動します。

2. 左側のナビゲーションペインで、ログと監査 > SQL インサイト を選択します。

3. [SQL Explorer を有効にする] をクリックします。

   説明

   現在の Alibaba Cloud アカウントで DAS Enterprise Edition が有効になっていない場合は、画面の指示に従って DAS Enterprise Edition を有効にします。

4. 右側のページで、機能タブをクリックして詳細を表示します。

   • [検索 (監査)]：データベース、ステータス、実行時間など、SQL 文と関連情報をクエリおよびエクスポートします。

   • [SQL インサイト]：

     • [時間範囲の表示]: SQL エクスプローラーの結果を表示する時間範囲を選択します。選択した時間範囲内のすべての SQL ステートメントの 実行期間の文布、実行時間、および 実行回数 を表示できます。また、選択した時間範囲内のすべての SQL ステートメントの詳細を 完全なリクエスト統計 エリアで表示し、ローカルマシンにエクスポートすることもできます。

       説明

       • 一度に最大 1,000 件の SQL ログをエクスポートできます。より広い時間範囲またはより多くの SQL ログを取得するには、「検索 (監査)」機能を使用します。

       • SQL インサイト を有効にすると、30 分後に監査ログを表示できるようになります。

     • [比較リストの表示]：SQL Explorer の結果を比較する時点を選択します。すべての SQL ステートメントの 実行期間の文布、実行時間、および 実行回数 の比較結果を表示できます。また、比較リストのリクエスト エリアで詳細な比較結果を表示することもできます。

     • [ソース統計]: SQL ソースの統計を収集する時間範囲を選択します。選択した時間範囲内のすべての SQL ステートメントのソース情報を表示できます。

     • [SQL レビュー]: 選択した期間とベースライン期間におけるデータベースクラスターのワークロード分析、およびデータベースクラスターで実行される SQL ステートメントの詳細な分析を実行します。 この機能では、データベースクラスターのインデックス最適化の提案、SQL 書き換えの提案、上位 SQL ステートメント、新規 SQL ステートメント、失敗した SQL ステートメント、SQL 機能分析、実行が変更された SQL ステートメント、パフォーマンスが劣化した SQL ステートメント、および上位トラフィックテーブルが表示されます。

     • [関連する SQL の特定]: 表示するメトリクスを選択し、分析 をクリックします。1〜5 分後、システムは、選択した時間範囲内で、選択したメトリクスの傾向と最も類似した SQL ステートメントをその詳細とともに特定します。

     • [トラフィックリプレイとストレステスト]：今後の短期的なビジネスピークやデータベーススキーマの変更、特にインデックスの変更の前に、トラフィックリプレイとストレステストを使用して、データベースクラスターの仕様をスケールアップする必要があるかどうかを確認できます。これにより、実際のビジネスシナリオでの実際の結果が検証され、変更が本番環境に適用された後の障害のリスクが軽減されます。

     • [セキュリティ監査]: 高リスク操作、SQL インジェクション、新しいアクセスソースなどのリスクを自動的に識別します。

     • [トランザクション分析]: DAS Enterprise Edition V3 のホットストレージデータに基づき、選択された スレッド および時間範囲内のトランザクション詳細を分析し、各タイプのトランザクション数を統計分析してトレンドチャートを作成します。

SQL ログの保存期間の変更

1. PolarDB コンソールにログインし、左側のナビゲーションペインでクラスターをクリックします。クラスターがデプロイされているリージョンを選択し、クラスター ID をクリックしてクラスター詳細ページに移動します。

2. 左側のナビゲーションペインで、ログと監査 > SQL インサイトを選択します。

3. 右上隅にある [サービス設定] をクリックします。

4. 保存期間を変更し、OK をクリックします。

   説明

   • DAS Enterprise Edition V3 を有効にしている場合は、各サブ機能のデータ保存期間を変更できます。

   • SQL Explorer and Audit データのストレージスペースは DAS によって提供され、データベースクラスターのストレージスペースを占有しません。

SQL Explorer and Audit の無効化

1. PolarDB コンソールにログインし、左側のナビゲーションペインで クラスター をクリックします。クラスターがデプロイされているリージョンを選択し、クラスター ID をクリックしてクラスター詳細ページに移動します。

2. 左側のナビゲーションペインで、ログと監査 > SQL インサイト を選択します。

3. [サービス設定] をクリックし、SQL Explorer and Audit を無効にします。

   DAS Enterprise Edition V3 を有効にしている場合は、すべての SQL Explorer and Audit 機能のチェックボックスをオフにします。

   説明

   • Simple Log Service の CloudLens for PolarDB で、PolarDB for MySQL の監査ログ収集機能を有効にしている場合、システムは対応する PolarDB for MySQL の SQL Explorer 機能を自動的に有効にします。したがって、PolarDB for MySQL の監査ログ収集機能も無効にする必要があります。詳細については、「データ収集の有効化」をご参照ください。

   • SQL Explorer 機能が無効になると、SQL 監査ログは削除されます。SQL Explorer 機能を無効にする前に、SQL レコードをエクスポートしてください。SQL レコードのエクスポート方法の詳細については、「SQL ログレコードのエクスポート」をご参照ください。

4. OK をクリックします。

監査ログのサイズと消費量の詳細の表示

1. Alibaba Cloud 管理コンソールにログインします。ページの右上隅で、[費用] を選択します。

2. 左側の [費用とコスト] ナビゲーションペインで、請求書 > 請求書の詳細 を選択します。課金項目 列が sql_explorer であるコスト詳細を表示します。

3. 請求詳細 タブで 請求明細 タブをクリックし、検索条件を インスタンス ID に設定して検索します。課金項目 列が sql_explorer であるコスト詳細を確認します。

新しいバージョンへの移行

1. PolarDB コンソールにログインし、左側のナビゲーションペインで クラスター をクリックします。クラスターがデプロイされている [リージョン] を選択し、クラスター ID をクリックしてクラスターの詳細ページに移動します。

2. 左側のナビゲーションペインで、ログと監査>SQL インサイト をクリックします。

3. 表示される「SQL エクスプローラーを SQL エクスプローラーと監査にアップグレード」ダイアログボックスで、アップグレード をクリックします。

Enterprise Edition 間での SQL Explorer and Audit データの移行

Enterprise Edition V1 と比較して、Enterprise Edition V2 は基盤となるストレージアーキテクチャを変更し、ホット/コールド混在ストレージを使用して効率を向上させ、使用コストを削減します。ホット/コールド混在ストレージを基盤として、Enterprise Edition V3 は使用する機能ごとに課金項目を分割します。課金がより柔軟になり、使用コストが低くなります。

データベースクラスターが Enterprise Edition V3 をサポートしている場合、DAS Enterprise Edition V1 または V2 のデータを Enterprise Edition V3 に移行して、より有利な価格設定を利用できます。詳細については、「DAS Enterprise Edition のバージョン間でデータを移行する方法」をご参照ください。

よくある質問 (FAQ)

• リソースプランを使用して SQL Explorer の料金を相殺できますか。

  いいえ。SQL Explorer 機能は従量課金にのみ対応しています。サブスクリプションには対応しておらず。

• SQL Explorer のすべてのリクエスト統計エリアにある logout！ ステートメントとは何ですか？

  logout！ は、接続が切断されたことを示します。 logout！ の期間は、最後のインタラクションの時刻と logout！ が発生した時刻との差で、接続のアイドル期間を表します。 ステータス 列の値 1158 は、ネットワーク接続が切断されたことを示します。 考えられる原因は次のとおりです。

  • クライアント接続がタイムアウトしました。

  • サーバーが異常に切断されました。

  • interactive_timeout または wait_timeout の期間を超えたため、サーバーが接続をリセットしました。

• SQL Explorer のソース統計に % のアクセスソースが表示されるのはなぜですか。

  これは、ストアドプロシージャを使用するときに発生する可能性があります。次の例は、この状況がどのように発生するかを示しています：

  説明

  次の例では、データベースクラスターは PolarDB for MySQL、テストアカウントは test_user、テストデータベースは test_db です。

  1. PolarDB コンソールで、標準アカウントと、そのアカウントがアクセスを許可されているデータベースを作成します。詳細については、「標準アカウントの作成」をご参照ください。

  2. テストアカウントを使用して、コマンドラインからデータベースクラスターに接続します。詳細については、「コマンドラインを使用してクラスターに接続」をご参照ください。

  3. テストデータベースに切り替え、次のストアドプロシージャを作成します。

     -- テストデータベースに切り替え
     USE test_db;

     -- ストアドプロシージャの作成
     DELIMITER $$
     DROP PROCEDURE IF EXISTS `das` $$
     CREATE DEFINER=`test_user`@`%` PROCEDURE `das`()
     BEGIN
         SELECT * FROM information_schema.processlist WHERE Id = CONNECTION_ID();
     END $$
     DELIMITER ;

  4. 権限のあるアカウントを使用してデータベースクラスターに接続します。詳細については、「権限のあるアカウントの作成」および「コマンドラインを使用してクラスターに接続」をご参照ください。

  5. ストアドプロシージャを呼び出します。

     -- テストデータベースに切り替え
     USE test_db;

     -- ストアドプロシージャの呼び出し
     CALL das();

     -- 呼び出し結果
     +-----------+-----------+---------+---------+---------+------+-----------+-------------------------------------------------------------------------+
     | ID        | USER      | HOST    | DB      | COMMAND | TIME | STATE     | INFO                                                                    |
     +-----------+-----------+---------+---------+---------+------+-----------+-------------------------------------------------------------------------+
     | 269660316 | test_user | %:46182 | test_db | Query   |    0 | executing | SELECT * FROM information_schema.processlist WHERE Id = CONNECTION_ID() |
     +-----------+-----------+---------+---------+---------+------+-----------+-------------------------------------------------------------------------+

• 監査ログリストに表示されるデータベース名が SQL 文のデータベース名と異なるのはなぜですか。

  ログリストに表示されるデータベース名はセッションから取得されます。SQL 文のデータベース名はユーザーによって指定され、ユーザーの入力またはクロスデータベースクエリや動的 SQL などのクエリ設計に依存します。2 つの名前は異なる場合があります。

• SQL Explorer and Audit を有効にすると、データベースのパフォーマンスに影響しますか。影響はどの程度ですか。

  はい。ただし、影響は非常に小さく、ほとんど認識できません。

  リソース使用量は次のとおりです：

  • CPU と メモリ：消費量は非常に低く、ほとんど無視できます。

  • ストレージスペース：主に監査情報を保存するために使用されます。ただし、DAS Enterprise Edition が提供する SQL Explorer and Audit 機能は、DAS が提供するストレージスペースを使用し、データベースクラスターのストレージスペースを占有しません。

  • ネットワーク：ネットワークパフォーマンスへの影響はありません。

  • ディスクパフォーマンス：監査データはデータベースクラスターのディスク上ではなく DAS 側に保存されるため、ディスクパフォーマンスへの影響はありません。

• クラスターで UPDATE 文が実行されました。監査ログによると、この SQL文で影響を受けた行数は 1 です。しかし、テーブルのデータは更新されず、変更前の状態のままです。この問題をトラブルシューティングして解決するにはどうすればよいですか。

  • トラブルシューティング手順：

    1. 監査ログで SQL ステートメントを見つけ、そのスレッド IDを取得します。 次に[高度な検索を有効にする]をクリックし、スレッド IDで検索します。 現在のスレッドで AUTOCOMMIT が無効になっているかどうか、また無効になっている場合は、明示的な COMMIT があったかどうかを確認します。

       説明

       (推奨) スレッド ID のみで検索を絞り込みます。ログが大量に返される場合は、必要に応じて他の検索条件を組み合わせてログの量を減らすと、分析や問題の特定が容易になります。

    2. 上記の方法で問題が特定できない場合は、データベースとテーブルの復元およびログ解析を使用して、変更が成功した記録が存在するかどうかを確認できます。

    説明

    このトラブルシューティング手順では、UPDATE 文はビジネスロジックの最終ステップとして扱われます。この変更が完了した後、データは変更されないままとなるため、その後に変更や削除が発生したかどうかをさらに確認する必要はありません。その後に変更が発生した場合は、関連する SQL 操作によってデータが変更されたかどうかを確認し続ける必要があります。

  • 問題のシナリオ：

    • AUTOCOMMIT が無効化されており、SQL文がコミットされていない: トラブルシューティング手順から、このリクエストが実行中に AUTOCOMMIT を無効化し、その後明示的な COMMIT を発行しなかったため、データが変更されなかったことがわかります。

    • スレッド ROLLBACK: 同じトランザクションセッションで実行される操作は、すべて成功するか、すべて失敗します。 ロールバックが発生した場合、すべての操作がロールバックされます。 トラブルシューティングの手順に従い、このリクエストの後に ROLLBACK 操作が発生したかどうかを確認してください。