September 19, 2025 at 11:43 am
We have a BI-application that connects to input tables on a SQL Server 2022 Standard edition. This is installed on a Windows Server 2022 in Azure with the size Standard E32s v5, having 32 vCPUs, 256 GB RAM, 32 data disks and 51200 max IOPS.
The SQL Server is used for reading, updating and writing data through ETL-jobs, and as mentioned to directly connect from the BI-application to manipulate data, through ODBC-connectors.
When doing budgeting in the company, several users manipulate input tables in the BI-application, indirectly manipulating the SQL Server tables. Then again the SQL tables have triggers to perform logiq that recalculates affected data. We also have users reading data from tables and simply modifying this without any triggers. These tables are not used in the budgeting process. However we're experiencing that users manipulating these simple tables have huge delays when the budget process is ongoing. Meaning that the queries generated are being delayed because of other jobs on the SQL Server, even though the tables are not related.
We're struggling to find out why this is happening, and what we can do to make performance better. We recently upgraded the Windows Server that SQL Server is running on to double vCPUS, RAM and max IOPS, but it doesn't seem to have any effect.
Can someone please help us understand what could be the problem?
I have some hypotheses, but not enough knowledge to determine if it's actually the problem:
-Could it be that the SQL Server being Standard edition caps the performance, thus it could be solved by upgrading to Enterprise?
-It could not be deadlocks on the simple tables, since they are not affected by the budgetting tables, but could it be deadlocks on RAM-usage etc?
-Could it be limitations on the connection itself between our BI application and the SQL Server?
-Other things?
Viewing post 1 (of 1 total)
You must be logged in to reply to this topic. Login to reply