If a stored procedure name includes the name of a database and it is copied to a different database, the database name is not updated. When DPA shows information about the copied stored procedure, the hash is the same as the first and the information appears to be incorrect.

If you experience this issue, complete the following steps:

1. Run the following command against the DPA repository database (replacing <HashValue> with the stored procedure's hash value):

   delete from ignite.CONST_<DBID> where H = '<HashValue>'

2. Restart DPA.

When registering an Azure SQL database, if you let DPA create the monitoring user and select an Azure Active Directory (AD) user as the privileged user, registration fails on the last step with the message Connection test to database as monitoring user failed.

During registration, SQL Server might return the following error in the registration wizard:

TLS handshake failed. Could not connect to the server using SSL.

This is accompanied by the following error in the wizard.log:

The server selected protocol version TLS10 is not accepted by client preferences [TLS13, TLS12]

This happens because the server (for example, a server running SQL Server 2008 R2) is not patched to a version that supports newer TLS 1.2 or 1.3, which DPA requires for secure communication. This requirement is inherited from the JDK shipped with DPA, which disables TLS 1.0 and 1.1 by default. This occurs in JDK 11.0.11 and later.

To resolve this issue, patch SQL Server to a newer Service Release or Cumulative Update that contains support for TLS 1.2 or later. See this Microsoft KB article for information about each SQL Server version.

If you cannot apply the resolution, you can use the following as a workaround and continue using TLS 1.0. (This workaround is not recommended because it reduces security.)

1. Open the following file in a text editor (or the corresponding file if you are using custom Java):

   <DPA_Home>\iwc\jre\conf\security\java.security

2. Find jdk.tls.disabledAlgorithms.

3. Remove TLSv1, TLSv1.1. Then save the changes.

4. Restart DPA.

If the file containing the DPA SQL authentication password is misconfigured, the DPA Options page does not open. This file can become misconfigured when password protection for DPA features that allow custom SQL is configured, and a password containing '<' or '>' characters was not enclosed with CDATA when it was entered.

1. Open the following file in a text editor:

   <DPA-install-dir>\iwc\tomcat\ignite_config\iwc\security\sqlauth.xml

2. Look for invalid XML such as the following (shown in red):

   <entry key="sql.authentication.password">
   <![USER_PASSWORD]]<
>/entry>

3. Reenter the password enclosed in CDATA, and edit the XML so that it is valid. For example:

   <entry key="sql.authentication.password">
  <![CDATA[MyPasswordWith<SpecialCharacters>]]>
</entry>

4. Save the file.

   Changes take effect immediately. The password in the sqlauth.xml file is encrypted the first time DPA prompts a user to enter it.

For MySQL 8.0, the default authentication plug-in has changed from mysql_native_password to caching_sha2_password. If you attempt to create a MySQL 8.0 repository database and allow DPA to create the repository user, the process fails because DPA cannot authenticate a user created with the default option.

1. Create the repository user manually and specify that the mysql_native_password plugin be used to authenticate that user. For example:

   CREATE USER 'userName'@'localhost' IDENTIFIED WITH mysql_native_password BY 'userPassword';

   You can verify user creation by querying the mysql.user table:

   select user,host,plugin from mysql.user;

2. Grant the required privileges to the user. See the GRANT statements in the script available through the Repository Creation Wizard.
3. On step 2 of the Repository Creation Wizard, select Provide the repository user. Then enter the user name and password of the user you created.

For MySQL 8.0, the default authentication plug-in has changed from mysql_native_password to caching_sha2_password. If you attempt to register a MySQL 8.0 instance and allow DPA to create the monitoring user, registration fails because DPA cannot authenticate a user created with the default option.

1. Create the monitoring user manually and specify that the mysql_native_password plugin be used to authenticate that user. For example:

   CREATE USER 'userName'@'localhost' IDENTIFIED WITH mysql_native_password BY 'userPassword';

   You can verify user creation by querying the mysql.user table:

   select user,host,plugin from mysql.user;

2. Grant the required privileges to the user. See the GRANT statements in the script available through the Register Instance Wizard.
3. On step 2 of the Register Instance Wizard, select I'll create the database user. Then enter the user name and password of the user you created.

If DPA is monitoring non-distributed SQL Server Availability Groups (AGs) on a server and you add a distributed AG to the server, DPA stops monitoring the non-distributed AGs.

When you monitor a SQL Server 2017 database instance that runs on a Linux server:

• The O/S CPU Utilization resource always shows usage at 100%.
• The Instance CPU Utilization resource always shows usage at 100%.
• The O/S Memory Utilization resource always shows usage at 0%.

When you monitor a SQL Server 2019 database instance that runs on a Linux server:

• The O/S CPU Utilization resource always shows usage at 100%.
• In some cases, the Instance CPU Utilization resource always shows usage at 100%.

Microsoft reports these values.

When DPA loses its connection to a monitored SQL Server instance (for example, when the DPA server is rebooted), and Windows authentication is used, DPA is sometimes unable to reconnect to the instance. This can happen if DPA attempts to connect before SQL Server has been able to connect to Active Directory. DPA interprets the rejected connection attempt as possibly occuring because the credentials were incorrect. To avoid being locked out of the account, DPA does not keep trying to reconnect. Messages such as the following appear in the logs:

Monitor for database [databaseName] failed to start due to [username and/or password must be updated due to previous login failure; if the credentials have not changed for this database, stop the monitor, wait for the monitor to stop, then start the monitor.].

When a SQL Server Availability Group (AG) is registered for monitoring through the listener, duplicate files collected through polling are not handled correctly in some situations, which can cause monitoring to fail. Errors such as the following can appear in the logs:

DEBUG (2021-04-03T17:16:50,214+0300) [repositoryManager-thread-23] {name=DBSERVER02 via AGLISTENER01} DatabaseMonitorJobListener:62 - Stopping monitor in SummaryPollJob

Loading the Host Disk metrics on the Resources page may take a long time when the host has a large number of disks. On new DPA installations, indexes to avoid this issue are created in the DPA repository. But if you upgraded from DPA 2021.1 or earlier, these indexes must be created manually.

1. From the DPA menu, click Options.

2. Under Support > Utilities, click Review DPA Repo Schema.

   If your DPA is missing some indexes you are provided with a SQL script to manually create them.

3. Follow the instructions on the page to create the missing indexes.

DPA cleanup jobs might not run properly on tables storing the historical plans, causing the repository to grow. On new DPA installations, indexes to avoid this issue are created in the DPA repository. But if you upgraded from DPA 2021.1 or earlier, these indexes must be created manually.

1. From the DPA menu, click Options.

2. Under Support > Utilities, click Review DPA Repo Schema.

   If your DPA is missing some indexes you are provided with a SQL script to manually create them.

3. Follow the instructions on the page to create the missing indexes.