PolarDB:SQL Explorer

機能

Database Autonomy Service (DAS) は、全リクエストデータの収集とセキュリティ監査に基づき、検索、SQL Explorer、セキュリティ監査、トラフィック再生およびストレステストなどの機能を統合しています。DAS を使用すると、SQL ステートメントの詳細を取得したり、幅広いパフォーマンスの問題をトラブルシューティングしたり、高リスクのソースを特定したり、クラスターのスケーリングが必要かどうかを判断したりできます。これにより、サービストラフィックのピークに対応できます。

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

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

  • SQL レビュー：グローバルな SQL ワークロード分析機能を提供し、データベースインスタンス内の不審な SQL ステートメントを迅速に特定・分析し、最適化の提案を受け取ることができます。詳細については、「SQL レビュー」をご参照ください。

  • トラフィック再生およびストレステスト：トラフィック再生およびストレステスト機能を提供し、インスタンスの仕様をスペックアップする必要があるかどうかを検証して、サービストラフィックのピークに効果的に対応できます。詳細については、「トラフィック再生およびストレステスト」をご参照ください。

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

  • トランザクション分析 機能を使用すると、指定された時間範囲内で特定の スレッド のトランザクションタイプ、トランザクション数、および詳細を表示できます。これにより、トランザクションの観点からデータベースパフォーマンスを理解・分析・最適化できます。詳細については、「トランザクション分析」をご参照ください。

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

対応リージョン

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

影響

有効にすると、SQL Explorer はすべての DQL、DML、DDL 操作を記録します。この情報はデータベースカーネルから出力され、CPU 使用量は最小限です。

注意事項

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

課金

SQL Explorer および監査の有効化

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

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

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

   説明

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

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

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

   • SQL インサイト：

     • 時間範囲の表示：時間範囲を選択して、SQL Explorer の結果を表示します。選択した時間範囲内のすべての SQL ステートメントについて、実行期間の文布、実行時間、および 実行回数 を表示できます。また、完全なリクエスト統計 エリアで、すべての SQL ステートメントの詳細情報を表示およびエクスポートできます。

       説明

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

       • SQL インサイト を有効化した後、監査 ログを表示できるようになるまで 30 分ほどお待ちください。

     • 比較リストの表示：SQL Explorer の結果を比較したい時刻を複数選択します。実行期間の文布、実行時間、および 実行回数 に基づいて、すべての 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 および監査データのストレージ領域は DAS が提供しており、ご利用のデータベースクラスターのストレージ領域を占有しません。

SQL Explorer および監査の無効化

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

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

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 インサイト をクリックします。

3. SQL Explorer を「SQL Explorer および監査」にアップグレード ダイアログボックスで、アップグレード をクリックします。

Enterprise Edition 間でのデータ移行

Enterprise Edition V1 と比較して、Enterprise Edition V2 はホットストレージとコールドストレージを組み合わせたハイブリッドストレージアーキテクチャを採用することでコストを削減しています。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 のシナリオなど）に依存します。そのため、これら 2 つのデータベース名が一致しない場合があります。

• 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 操作が発生したかどうかを確認するには、トラブルシューティング手順に従ってください。