Limiting the CPU/Memory utilization for a Query in SQL server 2008R2

Question

We have an AD-HOC process from the application team which is fetching data from one of our heavily used OLTP databases in SQLserver to migrate the data into MongoDB.

During the performance measure we can see that part of their run while fetching data from this sql server there is a spike in CPU for almost an hour, spiking to almost 60-80%.

Therefore to reduce this impact we are thinking to use Resource Governor to limit the CPU/Memory resources. I have never used RG, but reading the blogs seems it can be ideal.

Please suggest if this can be achieved or any better suggestions per your experience.

The activity above is monthly once fetching around 80 millions of data on 5 TB database in SQL server 2008R2

Answer 1

The short answer is 'Yes'. You can use RG to limit the CPU consumption of that process. Note that RG is only available in Enterprise and Data Center editions of SQL Server 2008R2. Use the Microsoft documentation excellent walk-through to learn about using RG: Resource Governor How-to Topics

Longer answer - RG does not address the root cause, it's a band aid to help with the symptoms, and make the disease less disturbing to the other users. If I were in your place, before resorting to RG solutions, I would invest some time trying to optimize the process itself. Although 'accessing 80 million rows' doesn't mean much, and just accessing data rows should not consume a lot of CPU. My experience has proven again and again that many processes that take hours, can be reduced to minutes (and in some cases, to seconds), and be made to consume orders of magnitude less resources than the original. Optimization effort should include not only the technicalities, such as proper indexing, schema tweaks, query syntax, and plan investigation, but also higher level evaluation of the process architecture and flow, does it do a full refresh or incremental update? how many times do you access the same tables? are there many temp tables involved? too many steps? Perhaps some redundant work being done? If you provide some more details about the process, and why it takes so much CPU, people here will be happy to help you.

Of course, there is no guarantee that you will succeed, and eventually you may end up resorting to use RG, but IMHO the effort is very worth while.

Answer 2

Since you're considering limiting resources during the window of operation, I understand you are concerned with the impact this query has on active transactions (since it's your OLTP database).

Therefore is it possible to:

1. use a snapshot and have your query use this (as a separate database) which can allieviate contention issues during the query window;

2. move the query 'out of hours'. It seems that this query is not time sensitive, so could it occur in the wee hours of the morning, as an example.

3. Change the schedule, so that this query is run weekly instead of monthly. That way you have a less 'harsh' impact during the process.
4. build data into a separate table/database/server during the month. then the query can hit those tables instead.
5. If your version is new enough, utilise in-memory tables or temp tables on your fastest storage subsystem.

Dallas