When you are planning data platform consolidation, it is very important to track down the changes in the overall system performance after the actual migration is done. You should understand the differences in the configurations and performance of the instances and databases. Then you will also understand better how well the actual planning work went, and which are the possible challenges in the data platform.
Let’s assume you had 100 servers with a total of 150 instances in your old data platform and then you carefully planned a new data platform. The new platform has only 30 target servers, each containing 5 instances on average. The container databases remained intact. Even though it is easier to maintain a significantly smaller set of servers, it should be able to ensure that sufficient service levels and performance are met in the new platform—or even exceeded—by understanding the correlation between the configurations and correlation between the performance counters between the old and new system. When the number of servers and CPU cores changes, this may also affect the instance level configuration settings such as Max Degree Of Parallelism and Cost Threshold For Parallelism. Also, the relative CPU workload may change if we are renewing the servers from the smaller server into bigger ones. Then it is a good idea to compare the processor queues as well.
What does this mean in practice? Well, you need to have a couple of things available: the instance and database level diagnostics results stored from the old data platform. Then you need to compare those results into new ones. You should include things like wait statistics, instance level configurations and index fragmentation per minimum. Wait statistics are a good way to point out where the hardware and DBMS bottlenecks are. Instance level configurations are important to fine-tune and balance the overall instance performance. Checking the indexes is important as they may become fragmented during the migration causing severe system slow-down.
Image: annual comparison on performance counters between the old and the new data platform in SQL Governor software.
In addition to this, you need consecutive monitoring data history at least from a couple of months on server, instance, and database level for all the important performance counters, such as average and maximum CPU utilization %, RAM usage, buffer cache hit ratio, page life expectancy, CPU time, IOPS, throughput, latencies, database growth, and such. Also, you need to be able to compare these figures between the old and new data platform. If, for example, the instance level CPU hits the ceiling continuously in an OLTP system, it will slow down the workload processing dramatically. Also, if there is insufficient RAM to handle all the data on the particular instance, the buffer cache hit ratio and page life expectancy start to fall down. What comes to the database level counters it is good to understand the actual IOPS, throughput and latencies so you can, compare the performance between the old and new storage system.
Actually, there is a software available that can do all the above, in addition to the consolidation planning and right-sizing of the system, making your job easier, faster and more accurate. It is called SQL Governor. With SQL Governor, you can run the diagnostics jobs, monitor your data platform, create consolidation plans from old to new data platform, and compare the monitoring data between the old and new data environment. This makes it easy to understand how the capacity is being used from different perspectives of performance, and you can focus in most important areas in terms of performance optimization and capacity management. This way, it is easy to follow-up for example that how the max degree of parallelism and cost threshold for parallelism changes will affect the actual wait stats and monitoring performance counters, and to compare their respective SLA’s between the old and new data platform. Or you can just simply compare the performance counter metrics between the old and the new system, and see what is the difference between them on the desired timespan.
Check out my previous articles related to SQL Governor: Why is SQL Server Consolidation Better Than Having a Scattered Environment, and Automated SQL Server Consolidation and Right Sizing – Save 50% Data Platform Costs.
Reference: Pinal Dave (https://blog.sqlauthority.com)
First appeared on How to Track Data Platform Service Level and Performance Before and After Consolidation?