PolarDB:SQL Explorer

特徴

Database Autonomy Service (DAS) は、全リクエスト収集とセキュリティ監査を使用して、検索、SQL Explorer、セキュリティ監査、本番トラフィック再現によるストレステストなどの機能を統合します。これにより、SQL 文に関する特定の情報を取得し、パフォーマンスの問題をトラブルシューティングし、重要な脅威のソースを特定し、サービストラフィックのピークに対応するためにクラスターをスケールアウトする必要があるかどうかを検証するのに役立ちます。

• 検索：SQL 文と、データベース、ステータス、実行時間などの対応する情報をクエリおよびエクスポートします。詳細については、「監査」をご参照ください。

• SQL Explorer：SQL 文の健全性を診断し、パフォーマンスの問題をトラブルシューティングし、サービストラフィックを分析するのに役立ちます。詳細については、「SQL Explorer」をご参照ください。

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

  • 本番トラフィック再現によるストレステスト：本番トラフィック再現によるストレステスト機能を提供し、サービストラフィックのピークに対応するためにインスタンスの仕様をスケールアウトする必要があるかどうかを検証するのに役立ちます。詳細については、「本番トラフィック再現によるストレステスト」をご参照ください。

  • セキュリティ監査：重要な SQL、SQL インジェクション、新しいアクセスソースなどの脅威を自動的に検出します。詳細については、「セキュリティ監査」をご参照ください。

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

  • クイックトランザクション分析：特定の SQL 文を含むトランザクションの開始文と終了文を見つけることができます。これにより、トランザクションがコミットされたかロールバックされたかを判断するのに役立ちます。詳細については、「クイックトランザクション分析」をご参照ください。

サポート対象リージョン

SQL Explorer と監査機能は、DAS Enterprise Edition を有効にした後にのみ使用できます。サポートされているリージョンは、Enterprise Edition のバージョンによって異なります。詳細については、「各エディションでサポートされているデータベースとリージョン」をご参照ください。

影響

SQL Explorer 機能は、実行されたすべての DQL、DML、および DDL 文の情報を記録します。DAS はデータベースカーネルから情報を取得しますが、消費する CPU リソースはごくわずかです。

注意事項

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

料金

SQL Explorer と監査の有効化

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

2. 左側のナビゲーションウィンドウで、ログと監査 > SQL Explorer を選択します。

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

   説明

   ご利用の Alibaba Cloud アカウントで DAS Enterprise Edition が有効になっていない場合は、画面の指示に従って有効にしてください。

4. 表示されたページで、タブをクリックして関連情報を表示します。

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

   • SQL Explorer：

     • 時間範囲の表示：時間範囲を選択して SQL Explorer の結果を表示します。選択した時間範囲内のすべての SQL 文の 実行期間の文布、実行時間、実行回数 を表示できます。また、完全なリクエスト統計 エリアですべての SQL 文の詳細情報を表示し、その情報をコンピューターにエクスポートすることもできます。

       説明

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

       • SQL Explorer を有効にして 30 分待つと、監査ログを表示できます。

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

     • ソース統計：SQL ソース統計の時間範囲を選択して、選択した時間範囲内のすべての SQL 文のソース情報を表示します。

     • SQL レビュー：選択した時間範囲とベースライン時間範囲のデータベースクラスターのワークロードを分析します。データベースクラスターで実行される SQL 文を詳細に分析し、インデックスの最適化の提案、SQL の再書き込みの提案、Top SQL、New SQL、Failed SQL、SQL 機能分析、実行計画が変更された SQL、パフォーマンスが低下した SQL、およびトップトラフィックテーブルを提供します。

     • 関連する SQL の特定：表示するメトリックを選択し、分析 ボタンをクリックします。1〜5 分後、指定した時間範囲内で選択したメトリックの変化傾向に最も一致する SQL 文とその詳細を特定できます。

     • 本番トラフィック再現によるストレステスト：短期的なビジネスのピークやデータベーススキーマ進化 (特にインデックスの変更) が迫っている場合、この機能を使用して、データベースクラスターの仕様をスケールアウトする必要があるかどうかを確認できます。これにより、実際のビジネスシナリオでの実際のパフォーマンスを検証し、サービス公開後の障害リスクを低減できます。

     • セキュリティ監査：高リスクな操作、SQL インジェクション、新しいアクセスソースなどの脅威を自動的に検出します。

     • トランザクション分析：DAS Enterprise Edition V3 のホットストレージデータに基づいて、選択したスレッド と時間範囲のトランザクション詳細を分析します。さまざまなタイプのトランザクション数について統計分析を行い、傾向チャートを作成します。

SQL ログのストレージ期間の変更

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

2. 左側のナビゲーションウィンドウで、ログと監査 > SQL Explorer を選択します。

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

4. ストレージ期間を変更し、OK をクリックします。

   説明

   • DAS Enterprise Edition V3 を有効にしている場合は、サブ機能ごとにデータストレージ期間を変更できます。

   • SQL Explorer と監査データのストレージ領域は DAS によって提供され、ご利用のデータベースクラスターのストレージ領域を占有しません。

SQL Explorer と監査の無効化

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

2. 左側のナビゲーションウィンドウで、ログと監査 > SQL Explorer を選択します。

3. サービス設定 をクリックして、SQL Explorer と監査を無効にします。

   DAS Enterprise Edition V3 を有効にしている場合は、SQL Explorer と監査のすべての機能を確認できます。

   説明

   • Simple Log Service の CloudLens for PolarDB 機能を使用して PolarDB for MySQL の監査ログ収集機能を有効にした場合、その PolarDB for MySQL クラスターに対して SQL Explorer 機能が自動的に有効になります。したがって、その PolarDB for MySQL クラスターの監査ログ収集機能も無効にする必要があります。詳細については、「データインジェストの有効化」をご参照ください。

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

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

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

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

2. 左側の 費用とコスト ナビゲーションウィンドウで、請求管理 > 課金詳細 を選択します。課金項目 列が sql_explorer に設定されている費用詳細を表示します。

3. 課金詳細 タブで、詳細 タブをクリックし、インスタンス ID で検索します。課金項目 列が sql_explorer に設定されている費用詳細を表示します。

   

新バージョンへの移行

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

2. 左側のナビゲーションウィンドウで、ログと監査 > SQL Explorer をクリックします。

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

異なる Enterprise Edition バージョン間での SQL Explorer と監査データの移行

Enterprise Edition V2 は、Enterprise Edition V1 から基盤となるストレージアーキテクチャを変更し、ホットデータとコールドデータのハイブリッドストレージを使用してコストを削減します。Enterprise Edition V3 は、このハイブリッドストレージ上に構築され、使用する機能に基づいてより柔軟な課金を提供し、コストをさらに削減します。

ご利用のデータベースクラスターが Enterprise Edition V3 をサポートしている場合、DAS Enterprise Edition V1 または V2 から Enterprise Edition V3 にデータを移行して、より低いコストの恩恵を受けることができます。詳細については、「異なる DAS Enterprise Edition バージョン間でデータを移行するにはどうすればよいですか？」をご参照ください。

よくある質問

• リソースプランを使用して 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 シナリオなど、クエリの設計に依存します。したがって、両者が一致しない場合があります。

• SQL Explorer と監査を有効にすると、データベースのパフォーマンスに影響しますか？もしそうなら、どのような影響がありますか？

  はい、しかし影響は最小限で、ほとんど感知できません。

  具体的なリソース消費は次のとおりです：

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

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

  • ネットワーク：ネットワークパフォーマンスには影響しません。

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

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

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

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

       説明

       スレッド ID のみでフィルタリング検索を行うことを推奨します。返されるログが多すぎる場合は、必要に応じて他の条件を組み合わせてログの数を減らし、分析しやすくしてください。

       

    2. この方法で問題が特定できない場合は、データベースとテーブルを回復し、ログを解析して、変更が成功した記録があるかどうかを確認することを検討してください。

    説明

    このトラブルシューティング手順は、UPDATE 文がビジネスロジックの最終ステップであることを前提としています。この変更後もデータは変更されないため、その後の変更や削除のチェックは不要です。その後に変更が発生した場合は、データが変更された原因となった関連する SQL 操作を引き続きチェックする必要があります。

  • 問題のシナリオ：

    • AUTOCOMMIT が無効で、SQL 文がコミットされていない：トラブルシューティング手順によると、このリクエストの実行中に AUTOCOMMIT が無効になっており、その後明示的な COMMIT が実行されていませんでした。これにより、スクリーンショットに示すように、データは変更されませんでした。

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