In some environments, SQL statements are not displayed on the SQL Performance Dashboard. The following error may appear in the Foglight Management Server logs:
ERROR [DBNAME-highPriorityPool-4-[DBSS_Top_SQLs]
com.quest.qsi.fason.core.collection.processor.InstanceProcessor - Failed to run DBSSTopSQLProcessor processor of DBSS_Top_SQLs collection.
java.lang.RuntimeException: Failed to execute collection [DBSS_Top_SQLs], reason=Failed to retrieve SQL text for SQL ID Caused by: java.lang.RuntimeException: Failed to retrieve SQL text for SQL ID ...Caused by: java.lang.RuntimeException: Failed to execute collection [DBSS_Top_SQLs], reason=[Foglight][SQLServer JDBC Driver][SQLServer]The server principal "foglightuser" is not able to access the database "realtime" under the current security context.-
This issue occurs when the Foglight monitoring login (foglightuser) cannot access the monitored database due to a mismatch between the login and the database user.
This is commonly seen when a database is restored from another SQL Server instance. Even if the same login name exists on both instances, the Security Identifier (SID) for the login may differ. SQL Server uses the SID—not the login name—to associate a login with a database user.
As a result, the restored database contains a user (foglightuser) whose SID does not match the SID of the login on the new instance. This causes access errors and prevents SQL PI from retrieving SQL text.
You can verify the SID mismatch by running the following query in both the original and restored databases:
USE [YourDatabaseName];
SELECT [uid], [name], [sid] FROM sys.sysusers WHERE name = 'foglightuser';
publicdb_datareaderdb_ddladmin (if required)If the SID mismatch is confirmed, drop and recreate the user in the affected database:
USE [YourDatabaseName];DROP USER [foglightuser];CREATE USER [foglightuser] FOR LOGIN [foglightuser];
This remaps the database user to the correct login SID on the current instance.
If you have a standard script for granting permissions to the foglightuser, re-run it on the affected (restored) database to ensure proper access.