Cloud SQL for SQL Server at GCP - Part II

In Part One, we dealt with the setting up of managed databases, and we will now go into more detail on how to scale up and scale down in Azure SQL DB.

If, so far, we have become accustomed to raising a tier and downloading a tier by choosing a tier from which everything will be affected and changed, we are now given the option to add memories, processors and storage.

This option is more dynamic because it can solve a specific problem. At the same time, the options we now have are innumerable, which may create confusion that will prevent us from making an informed decision and calculating costs in an effective way. Precisely for these reasons, I have prepared a comprehensive guide to help you understand things in depth, through detailed screenshots - here's the guide:

Enter the configuration screen by clicking the checkmark link:

Now the screen has split into several configuration options - we will focus on the hardware:

The relevant data, such as memory and CPU, must be changed.

We'll change the storage - note that a summary appears on the right.

After we click, mark, and choose to begin the process, a message will appear stating that the server will reboot to apply the changes.

When the server will be up after a few minutes - everything will be configured, according to your settings.

This is a very simple procedure, thanks to which you can test quite a few parameters and understand what is most effective for you.

If you want to check the CPU and memory, run the following queries:

 
  
-- CPU assigned to database
SELECT scheduler_id,
cpu_id,
status,
is_online
FROM sys.dm_os_schedulers
WHERE status = 'VISIBLE ONLINE'
-- Memory allocated to database
SELECT
*,
cntr_value / 1024 AS RAM_in_MB
FROM sys.dm_os_performance_counters
WHERE counter_name LIKE '%Target Server Memory%'