sql-server-maintenance-solution VS dba-dash

100% this. Separating tempdb has a huge impact, and Ola’s scripts are a must, for anyone who doesn’t know: https://ola.hallengren.com

Since you are new to SQL - https://ola.hallengren.com/ and http://whoisactive.com/downloads/ + https://www.sqlshack.com/monitoring-activities-using-sp_whoisactive-in-sql-server/ will make your SQL experience night and day. Learn these SPs/Tooling.

First, don't use maintenance plans. Full Stop. Use Ola Hallengren's Maintenance Solution or Minion Backup. dbatools even has a way to install and schedule Ola's jobs, including backups. Quick and easy.

Instead of trying to reinvent the wheel look at https://ola.hallengren.com/

Great advise. I tend to use this for SQL: https://ola.hallengren.com

Ya I use https://ola.hallengren.com for my DB maintenance. I typically have to fix existing non maintained WSUS / SUSDB Sups. I found one the other day with about 20K updates lol

Install Ola Hallengren's Maintenance Solution and schedule the Agent jobs to run the backups when you need them (and make sure you understand the difference between FULL, LOG and DIFF backups, and when you should use each). Configure it with the URL for your Azure Blob Storage. You will also need to create a Credential for SQL Server to use to authenticate to Azure Blob Storage.

SQL Server database maintenance. You don't need to be a SQL expert - just set it and forget it with this: https://ola.hallengren.com/

DBA Dash backup collection query for reference. Have you tried running the query in SSMS and timed the execution?

It's still important to have alerts and DBA Dash doesn't have anything built in to do this. It is possible to create alerts based on the data collected in the repository database. There are some sample alerts here that might be worth a look. Hope this helps!

You can almost get everything through SQL with sys.dm_os_volume_stats:https://github.com/trimble-oss/dba-dash/blob/main/DBADash/SQL/SQLDrives.sqlThis won't include volumes that don't have any SQL files on them. e.g. o/s volume, backup volume etc.

I would definitely still recommend sp_whoisactive though - it's a great tool. Also, monitoring tools act like a flight recorder providing valuable information that you can use to diagnose performance issues after the event. I created DBA Dash an open-source monitoring tool that you might want to take a look at if you are interested in using a monitoring tool. Also, enabling query store at the DB level provides useful data to troubleshoot and fix performance issues.

I created a monitoring tool called DBA Dash that's open source if you are interested in a free monitoring tool. https://github.com/trimble-oss/dba-dash When adding a connection to monitor click the checkbox for slow query capture and it will capture all queries that take longer than 1 second to run. This is similar to your profiler trace. It also captures a lot of other data that is useful to troubleshoot performance issues. As mentioned query store is great - enable this and use in combination with dba dash. (Or other monitoring tool)

sp_BlitzFirst, sp_whoisactive. Look at query store if you have this enabled. If its a bad plan query store can help you identify and fix it. Look at cpu, io performance metrics etc. If you can't create procs for some reason you could add ## to the name to make them global temp stored procs. The procs will live as long as the session is left open that created them. Consider a utility database where you can add diagnostic stored procs. Ideally consider a monitoring tool. I created a free open source one called DBA Dash. https://github.com/trimble-oss/dba-dash