4.

MONITOR AND OPTIMIZE OPERATIONAL RESOURCES

*************************************************

4.1 LAB – AZURE MONITOR – AZURE SQL DATABASE

METRICS

How you can view your metrics in Azure Monitor.

4.2 LAB – AZURE MONITOR – SET UP ALERTS

How you can set up alerts in Azure Monitor itself.

1- Select the resource on which you want to create the alert rule.

2- Add the condition, either based on any metric or activity log.

3- Create action group. What action group you want to perform if the
alert gets generated.

4- Provide the alert rule details.

5- It takes around 10 minutes for the alert rule to take effect.

4.3 LAB – AZURE SQL DATABASE – INTELLIGENT INSIGHTS

 This is a feature that is available for the Azure SQL database

and the Azure SQL Managed Instance service.

 It uses in-built intelligent to continuously monitor the

database and detect any disruptive events that can cause
poor performance.

 It can also give you the following insights:

o Can detect any sort of database performance

degradation.

 They are recorded in SQL Insights log with the

following properties:

 Observed time range: this is the start and

end time for the period of the detected
insight.
 Impacted metrics: this can include ‘Query
duration increase’, ‘Timed-out requests’
and ‘Errored-out requests.’
 Impact value: you get the value of the
metric that gets measured.
 Impacted queries and error codes: this can
be used to easily correlate to the affected
queries.
  Root cause analysis: this is the root cause
analysis of the issue identified in a human-
readable format.

o Any performance improvement recommendations.

 To configure the Intelligent Insights feature, you have to

enable the streaming of Diagnostic Logs.

 The logs can be streamed onto a Log Analytics Workspace (a

central resource that is available for collection of all of your
logs).

 You can then use the Azure SQL Analytics feature in Log
Analytics to get the required information when it comes to
Intelligent Insights.

1- First, lets create a new resource: ‘Log Analytics Workspace’. We want

to direct the logs from the diagnostic settings in SQL database, onto a
Log Analytics Workspace.
2- When creating the ‘Log Analytics Workspace’ make sure that it’s in
the same location as the Azure SQL Database.

3- The creation will just take a couple of minutes.

4- Go to the Azure SQL Database, to its ‘Diagnostic Settings’.

 5- Go to ‘+ Add diagnostic setting’.

6- Name the diagnostic setting, select the data to send to our

destination, select the destination (‘Log Analytics Workspace’), and
hit ‘Save’.
 4
1
2
3

7- Go to the ‘Log Analytics Workspace’, to ‘Logs’. The diagnostic

setting will automatically start creating a table and pushing data
information onto the table in the Log Analytics Workspace. But this can
take from 15 to 20 minutes, so wait for some time and come back once
we have the data in place. After some time, refresh the page for Log
Analytics Workspace, go to the ‘Logs’ section, you will see that under
‘LogManagement’ you now have a table named ‘Azure Diagnostics’:
In the query windows type ‘AzureDiagnostics’, hit ‘Run’, in the ‘Results’
page you will see all the various results, all the data that is being sent
onto the Log Analytics Workspace.

8- Next, go to ‘Workspace summary’ and click ‘+ Add’.

9- Over here, there is an ‘Azure SQL Analytics’ solutions in place that can
work on top of the Log Analytics Workplace. Click on it and ‘Create’,
and again on ‘Create’. Now it’s going to deploy that SQL Analytics
Solution, on top of Log Analytics. It will take around 5-10 minutes, not
only for the deployment of the solution, but also waiting for the
solution to take that data from the Log Analytics Workspace and give
us some visualization.
10- When you come back to your Log Analytics Workspace, if you go to
‘Workspace summary’, you now can see you have Azure SQL
Analytics, and that you have 1 Azure SQL Database in place.
If click on it you can get information about the database itself.

And if you go on to the database itself, you will get a summary about
the database itself when it comes to insights. Since we don’t have
anything much running on this underlying database, that’s why we
don’t have any issues that have been directed for the underlying
resources.
If you scroll to the right you will see if there are any sort of queries still
waiting stats, any database waits, the database metrics… a lot of
information.
4.4 AZURE SQL DATABASE – AUTOMATIC TUNING

 What is the Automatic Tuning Feature? This is a feature that

is available for the Azure SQL Database and the Azure SQL
Management Instance service.
 It uses in-built intelligence to continuously monitor the
queries executed on the database and also has the ability to
improve their performance automatically.

 There are 3 settings available for Automatic Tuning:

o Create Index – this identifies if the (automatic) creation

of an index on a table will have the ability to improve
the performance of the queries running against the
table. This feature will automatically create the index. It
will also verify whether the creation of the index has an
improvement on the performance of queries.

o Drop Index – this identifies redundant and duplicate

indexes. Here it checks if the indexes were not used in
the last 90 days. It performs this check daily. This
feature is not available for the Premium and Business
Critical service tiers.

o Force Last Good Plan – this identifies Azure SQL queries

that use an execution plan that is slower than the
previous good plan. It also identifies queries that used
the last known good plan instead of the regressed plan.

 Where is the Automatic Tuning Feature for an Azure SQL

Database?
Remember: if it creates an index, it also validates the performance of the
underlying queries after the creation of the index itself.

4.5 LAB – ELASTIC JOB AGENT - SETUP

 Understanding the Elastic Job Agent. In SQL Server, there is
the SQL Server Agent that can be used to schedule and
execute jobs on SQL Server.

 The SQL Server Agent is not available on Azure SQL Databases

– Single Databases.

 In order to execute jobs on a Single Database, you can use the

Elastic Job Agent feature.

 You first have to create a resource based on Elastic Job

Agents.

 During the creation, you will map the agent onto a job
database.

 The jobs make use of database scoped credentials to connect

to the databases specified by a target group.

 The databased scoped credential will be used in the master

database of the target server to iterate through the databases
on the server.

 The database scoped credentials need to be created in the job

database.

 All of the target databases need to have a login with sufficient

permissions for the job to complete successfully.

 A representation when it comes to using the database scope

credentials:
 First, you have your Job Database and your Target Master Database. You’ll also
have your Target User Database itself. The Elastic Job Agent will store information about the
jobs in the job database itself, and then the jobs will be executed on the Target User
Database. Now, in the Job Database, you have to create database scope credentials based
on master credentials and job credentials. The master credentials are the ones we will
create in the Target Master Database. For the job credentials in the Target Master Database,
you create the login based on the job credentials and any Target User Database you create
based on the job credentials.

4.6 LAB – ELASTIC JOB AGENT - SETUP

4.7 LAB – USING THE QUERY STORE

 What is the Query Store feature?

o This is a feature that is available for the Azure SQL Database,

Azure SQL Managed Instance service and even for SQL Server
Instances as well.

o This feature provides insights on the query plan choices and

performance.
 o This can help administrators determine any sort of performance
differences that can occur based on query plan changes.

o The Query Store feature can capture a history of the queries,

plans and runtime statistics.

o You can enable the Query Store feature with the help of the
ALTER DATABASE SET option.

o The Query Store itself contains 3 stores:

 Plan Store – This is used for persisting the execution plan

information.
 Runtime Stats Store – This is used for persisting the
execution statistics information.
 Wait Stats Store – This is used for persisting the wait
statistics information.

 What information does the Query Store offer?

o Regressed Queries – this shows the queries and plans in

the Query Store.
o Here you can filter the results based on aspects such as
Duration (ms), CPU Time (ms).
o You can also force a plan by selecting a query and the
associated plan.
o You can also get information on the Overall Resource
consumption and the Top Resource consuming queries.
o You can also get wait statistics for queries.

 Some important aspects when it comes to the storage for

Query Store. VERY IMPORTANT FOR THE EXAM!!!!

o Max Size in MB
o Here you specify what is the maximum size of the Query
Store.
o Here Query Store will store the queries, execution plans
and statistics till the size of the database reaches the limit
specified by the Max size.
 o When the limit is reached, then Query Store will stop
collecting new data and will go into read-only mode.

o Data Flush Interval in Minutes

o This defines the frequency at which the data for Query

Store is persisted to the disk
o If your database workload does not have a large number of
queries and plans then you can consider using a higher
value for the Data Flush Interval.

o Statistics Collection Interval in Minutes

o This defines the level of granularity for the collected

statistics for the queries and plans.
o You can define a lower value if you need a finer granularity
for the statistics that are collected.

o Stale Query Threshold in Days

o This defines the retention period of the runtime statistics

and inactive queries.
o If historical data is not required, then you can choose to
reduce the time for the stale query threshold setting.

 How to use the Query Store feature.

4.8 USING RESOURCE GOVERNANCE

 What is Resource Governor?
o This is a feature that is available in SQL Server.
o This allows you to manage SQL Server workload and
system resource consumption.
o It enables you to limit the amount of CPU, physical I/O
and memory for the incoming application requests.
o Here you can base a workload as a set of similarly sized
queries.
o The resources of SQL Server can then be divided across
the different workloads.
  Let’s take an example wherein you had multiple
departments in a company that need to go ahead
and make use of data that is being hosted in a
SQL Server Instance. So, if you want to limit the
amount of CPU and other resources onto these
different departments based on their workloads,
you can make use of Resource Governor.
o It’s good for multi-tenant environments accessing a
single instance of SQL Server.
 As a simple example, I mentioned different
departments accessing a single instance of SQL
Server.
o In Resource Governor, you have:
 Resource Pools – This represents the physical
resources of the server.
 By default there are two resource pools created –
internal and default.
 Workload Groups – This is used as a container
for session requests that have the same
classification criteria.
 Here, again, you have two workload groups
created – internal and default.
 These are mapped to the respective resource
pools.

 Seeing where to enable Resource Governor.