SQL Server optimization for GR node

I believe you are asking this question in reference to the other question in the following link ?

https://softwareforums.aveva.com/heroes-hq/f/aveva-system-platform-and-omi/82467/development-environment-best-practices-for-large-systems

The articles you have found are basically guidelines how how to configure and optimize SQL Server for the use of Application Server.  They are not a be-all-and-end-all of the settings of SQL Server.  The optimization of SQL Server should be treated like a feedback loop.  It depends on how much your system is currently being used and the loading and adjusted accordingly.  In addition,  what is contained within the Galaxy DB also impacts the performance of the SQL Server.

With that said,  those articles need to be updated with the latest SQL Server versions supported by the latest System Platform version.

There are various factors that may impede the performance of the SQL Server and a review of your system will provide valuable insight as to how best to improve it based on overviewing the entire system.  Please reach out to me here via private messaging to have a further discussion.

Thank you for your questions! AVEVA product documentation typically does not provide documentation of third party products. Microsoft provides specific topics such as "Monitor and Tune for Performance - SQL Server". We will investigate providing guidance for SQL database and query optimization specific to AVEVA Application Server GR node and update our product documentation in an upcoming release.

There was previously a recommendation to run SQL on all CPUs except CPU0. aaGR uses CPU0 and was known to cause lockups or delays on larger systems. I'm not sure this is still a recommendation, maybe someone from Aveva can chime in on this.

Running a maintenance plan on the GR to reorganize the indexes can also help speed things up.

Running databases and especially temp databases on fast disks will help.

If running on a virtual machine, make sure the CPU resources are dedicated and not over provisioned.

You should also have a look at how many check-ins and deploys you have at any given time. Modern developers tend to check-in and deploy once per line of code they write. I think that would cause locks and wait times.