SQL Server Error 300

Error number

300

Severity

14 (user-correctable error)

State

Not documented by Microsoft (not reproduced here)

Product

Microsoft SQL Server Database Engine

Versions

All supported SQL Server versions (2016 to 2025), Azure SQL Managed Instance; the permission named differs on SQL Server 2022 and later (granular PERFORMANCE and SECURITY STATE permissions)

Category

Logins & Permissions

Last reviewed

23 October 2026

What it means

Error 300 means the login lacks a server-level or database-level permission, most often VIEW SERVER STATE, that a dynamic management view, monitoring tool or administrative feature checks before returning data.

Dynamic management views (DMVs) such as sys.dm_os_wait_stats or sys.dm_exec_query_stats expose server-wide state, so SQL Server checks a server permission before returning rows. When the login does not hold it, the engine raises 300 at severity 14, naming the permission and the securable ('server' in 'master' for server permissions), and typically adds Msg 297. Monitoring tools, ORMs and older client tools that read DMVs on connect are the usual sources.

On SQL Server 2022 and later, Microsoft documents granular permissions: server-scoped DMVs require VIEW SERVER PERFORMANCE STATE (or VIEW SERVER SECURITY STATE for security views) and database-scoped DMVs require VIEW DATABASE PERFORMANCE STATE. VIEW SERVER STATE still covers both. Our SQL Server 2025 lab could not raise 300 from a database user: database-scoped DMVs returned error 262 plus 297, and server-scoped DMVs under EXECUTE AS USER returned 15562, because an impersonated database user never carries server permissions.

Common causes

• A monitoring, APM or backup tool connects with a login that was never granted VIEW SERVER STATE (or VIEW SERVER PERFORMANCE STATE on SQL Server 2022 and later).
• An application or migration script queries DMVs such as sys.dm_exec_sessions with full details, sys.dm_os_wait_stats or sys.dm_exec_query_stats as a least-privilege login.
• A user granted only database permissions queries a server-scoped view; database-level grants never satisfy a server permission.
• Permissions were moved from VIEW SERVER STATE to a narrower granular permission on SQL Server 2022 and later, and the view needs the other half (performance versus security state).
• A DENY on the permission (or on the view) overrides a GRANT from a role.

Diagnose it

Read-only These queries only read metadata and dynamic management views. They do not change data, permissions or configuration, so they are safe to run first.

SELECT permission_name
FROM sys.fn_my_permissions(NULL, 'SERVER')
WHERE permission_name LIKE 'VIEW SERVER%'
ORDER BY permission_name;

SELECT HAS_PERMS_BY_NAME(NULL, NULL, 'VIEW SERVER STATE')   AS view_server_state,
       HAS_PERMS_BY_NAME(DB_NAME(), 'DATABASE', 'VIEW DATABASE STATE') AS view_database_state;

SELECT sp.name AS login_name, pe.permission_name, pe.state_desc
FROM sys.server_permissions AS pe
JOIN sys.server_principals AS sp ON sp.principal_id = pe.grantee_principal_id
WHERE sp.name = N'monitor_login'
  AND pe.permission_name LIKE 'VIEW%';

How to fix it

Each fix is labelled with what it changes. Try read-only checks and the least invasive fix first, and test changes outside production.

-- SQL Server 2022 and later
GRANT VIEW SERVER PERFORMANCE STATE TO [monitor_login];

-- SQL Server 2019 and earlier
GRANT VIEW SERVER STATE TO [monitor_login];

ALTER SERVER ROLE [##MS_ServerStateReader##] ADD MEMBER [monitor_login];

-- In the database concerned
GRANT VIEW DATABASE PERFORMANCE STATE TO [monitor_user];  -- 2022 and later
GRANT VIEW DATABASE STATE TO [monitor_user];              -- all versions

Examples

A monitoring login without VIEW SERVER STATE reads a DMV

Shown as widely reported for a login without the permission; not reproduced here because the lab does not create logins. On SQL Server 2022 and later the permission named can differ, following the granular permissions documented by Microsoft.

-- Connected as monitor_login, which has no server permissions
SELECT wait_type, wait_time_ms
FROM sys.dm_os_wait_stats;

VIEW SERVER STATE permission was denied on object 'server', database 'master'.
Msg 297, Level 16, State 1, Line 2
The user does not have permission to perform this action.

What a database user gets instead: 262 and 297 for a database DMV

Reproduced on SQL Server 2025 in a scratch database (here called Sales). The database-scoped check raises error 262 naming VIEW DATABASE PERFORMANCE STATE, followed by 297, not error 300.

CREATE USER monitor_user WITHOUT LOGIN;

EXECUTE AS USER = 'monitor_user';
SELECT TOP (5) object_id, row_count FROM sys.dm_db_partition_stats;
REVERT;

Msg 262, Level 14, State 1, Line 4
VIEW DATABASE PERFORMANCE STATE permission denied in database 'Sales'.
Msg 297, Level 16, State 1, Line 4
The user does not have permission to perform this action.

Server DMVs cannot be tested with EXECUTE AS USER

Reproduced on SQL Server 2025. A database user context is sandboxed to its database, so a server-scoped DMV fails with 15562 rather than 300. Test server permissions with the real login, or EXECUTE AS LOGIN.

CREATE USER monitor_user WITHOUT LOGIN;

EXECUTE AS USER = 'monitor_user';
SELECT TOP (5) wait_type FROM sys.dm_os_wait_stats;
REVERT;

Msg 15562, Level 16, State 2, Line 4
The module being executed is not trusted. Either the owner of the database of the module needs to be granted authenticate permission, or the module needs to be digitally signed.

How to prevent it

Create one login per monitoring tool and give it a documented set of read permissions (the granular state permissions on SQL Server 2022 and later, or VIEW SERVER STATE before that). Keep application logins free of server permissions so a 300 in an application log points straight at an unexpected DMV query.

When you test permissions, impersonate the login, not a database user: EXECUTE AS USER hides server permissions and produces different errors. See the SQL Server security lesson for how server and database permissions fit together.

Common questions

Learn more on CodeWithSQL

• SQL Server security: logins, users and permissions
• SQL Server performance problems and how to fix them

Official documentation

• System dynamic management views and functions: permissions (Microsoft Learn)
• Database engine events and errors 0 to 999 (Microsoft Learn)
• GRANT server permissions (Transact-SQL)

Last technically reviewed 23 October 2026; examples and diagnostics run on SQL Server 2025 (17.0.1145.4). Message text checked against the engine's sys.messages catalogue.