すべてのプロダクト
Search
ドキュメントセンター

Database Autonomy Service:セッション管理

最終更新日:Nov 13, 2024

データベースでパフォーマンスの問題または操作の例外が発生した場合、データベースのセッション情報に基づいて問題または例外をトラブルシューティングできます。 Database Autonomy Service (DAS) は、データベースインスタンスに関するセッション情報を表示し、セッションに対してO&M操作を実行できるセッション管理機能を提供します。 たとえば、セッションを終了し、データベースインスタンスに対して10秒間のSQL分析、SQLスロットリング、およびSQL最適化を実行できます。

前提条件

データベースインスタンスがDASに接続されており、正常なアクセス 状態です。

説明

DASは、ApsaraDB RDS for SQL Serverインスタンスのセッション管理機能を提供していません。

手順

このトピックでは、ApsaraDB RDS for MySQLインスタンスを使用して、セッション管理機能の使用方法を示します。

  1. DASコンソールにログインします。

  2. 左側のナビゲーションウィンドウで、インスタンスモニターをクリックします。

  3. 表示されるページで、管理するデータベースインスタンスを見つけ、インスタンスIDをクリックします。 インスタンス詳細ページが表示されます。

  4. 左側のペインで、インスタンスセッションをクリックします。

  5. セッション管理タブで、インスタンスのセッションセッション統計セクションにあるデータベースインスタンスに関するセッション情報を確認します。

    • インスタンスのセッション セクションでは、次の操作を実行できます。

      • 例外セッション、アクティブセッション、最長実行時間、CPU使用率、接続使用率などの情報を表示します。

      • セクションの右上隅にある10 秒 SQL 分析をクリックします。 表示されるダイアログボックスで、概要情報、低速クエリログ、SQLの概要など、10秒以内のクエリに関する情報を表示します。 詳細については、「10秒のSQL分析」をご参照ください。

      • SQL スロットリング をクリックします。 SQL スロットリング ダイアログボックスで、セッションのしきい値ベースのSQLスロットリングを有効にするパラメーターを設定します。 詳細については、「SQLスロットリング」をご参照ください。

      • 最適化 をクリックしてセッションを最適化します。 詳細については、「SQLの最適化」をご参照ください。

      • アクティブなセッションをエクスポートします。

      • セッションを終了します。

        セッションを終了するには、セッションが作成されたデータベースのアカウントとパスワードを入力する必要があります。 他のデータベースアカウントを使用して作成されたセッションを終了する権限を持つデータベースアカウントを使用することもできます。 たとえば、特権アカウントを使用できます。

        説明
        • セッションの ユーザー 列に、セッションの作成に使用されるデータベースアカウントを表示できます。

        • セッション履歴の終了 をクリックすると、終了したセッションのレコードを表示できます。

    • セッション統計 セクションでは、次の操作を実行できます。

      • ユーザー、アクセスソース、またはデータベースごとに概要情報とセッション統計を表示します。 サマリ情報は、セッションの総数、進行中のセッションの総数、および最長セッション期間を含む。

      • ユーザー、アクセスソース、またはデータベースごとにサマリー情報とセッション統計をエクスポートします。

よくある質問

Q: パーセント記号 (%) が [アクセスソース] 列に表示されるのはなぜですか。

A: ストアドプロシージャを使用すると、SQL Explorerタブの [ソース統計] タブの [アクセスソース] 列にパーセント記号 (%) が表示されることがあります。 この状況を再現するには、次の操作を実行します。

説明

この例では、データベースインスタンスはApsaraDB RDS for MySQLインスタンス、テストアカウントはtest_user、テストデータベースはtestdbです。

  1. データベースと標準アカウントを作成し、ApsaraDB RDSコンソールでデータベースに対する権限を標準アカウントに付与します。 詳細については、「アカウントとデータベースの作成」をご参照ください。

  2. CLIを使用して、test_userアカウントを使用してインスタンスに接続します。 詳細については、「データベースクライアントまたはCLIを使用したApsaraDB RDS For MySQLインスタンスへの接続」をご参照ください。

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

    -- Switch to the testdb database.
    USE testdb;
    
    -- Create a stored procedure.
    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. 特権アカウントを使用してデータベースインスタンスに接続します。 詳細については、「データベースクライアントまたはCLIを使用したApsaraDB RDS For MySQLインスタンスへの接続」をご参照ください。

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

    -- Switch to the testdb database.
    USE testdb;
    
    -- Call the stored procedure.
    CALL das();
    
    +--------+-----------+--------+--------+---------+------+-----------+-------------------------------------------------------------------------+
    | ID     | USER      | HOST   | DB     | COMMAND | TIME | STATE     | INFO                                                                    |
    +--------+-----------+--------+--------+---------+------+-----------+-------------------------------------------------------------------------+
    | 487818 | test_user | %:2065 | testdb | Query   |    0 | executing | SELECT * FROM information_schema.processlist WHERE Id = CONNECTION_ID() |
    +--------+-----------+--------+--------+---------+------+-----------+-------------------------------------------------------------------------+

Q: ApsaraDB RDS for MySQLインスタンスとPolarDB for MySQLクラスターで異常とマークされているセッションは何ですか。

A: 次のセッションは異常としてマークされます。

  • "Waiting for table metadata lock" エラーを報告するセッションなど、ブロッキングSQL文を含むセッション。 ブロッキングSQL文の実行時間が30秒を超えています。 ブロッキングSQL文は、長期間リソースを占有します。 その結果、他のSQL文の実行に失敗する可能性があります。 一般的なブロッキングSQLステートメントには、FLUSH TABLES WITH READ LOCKステートメントと、保留中のトランザクションによるメタデータロックを待つDDLステートメントが含まれます。

  • 30秒を超えるトランザクションを含むセッション。

  • 長期間コミットされていないトランザクションを含むセッション。 トランザクションがセッションで開始され、新しいSQL文が10秒を超えて実行されない場合、COMMITコマンドがコードから省略される可能性があります。 これは、トランザクションが長期間にわたってリソースを占有し、最も早い機会にリソースを解放することに失敗する可能性がある。