Update VerifyDeployment.ipynb

Author: amthomas46

02-DeployAndConfigure/verifydeployment/VerifyDeployment.ipynb

@@ -3773,7 +3773,7 @@
             "source": [
                 "Two VISIBLE ONLINE schedulers are what you would expect when 2 vCores are available for the SQL Server where you SQL Database is deployed.\r\n",
                 "\r\n",
-                "For a SQL Server deployment, you may normally look at DMVs like `sys.dm_os_sys_info` AND `sys.dm_process_memory` to see limts for CPU, memory, and workers. These DMVs are not exposed with Azure SQL Database, since the details of the host supporting the database are not exposed or controlled by the user. So the DMV `sys.dm_user_db_resource_governance` can be used to review capacities and limits for your deployed Azure SQL Database. Run and review the query results below and compare this to your Pricing Tier and the limits [documented](https://docs.microsoft.com/en-us/azure/sql-database/sql-database-vcore-resource-limits-single-databases) for your deployed tier."
+                "For a SQL Server deployment, you may normally look at DMVs like `sys.dm_process_memory` to see limts for CPU, memory, and workers. This DMVs is not exposed with Azure SQL Database, since the details of the host supporting the database are not exposed or controlled by the user. So the DMV `sys.dm_user_db_resource_governance` can be used to review capacities and limits for your deployed Azure SQL Database. Run and review the query results below and compare this to your Pricing Tier and the limits [documented](https://docs.microsoft.com/en-us/azure/sql-database/sql-database-vcore-resource-limits-single-databases) for your deployed tier. The `slo_name` is the Service Level Objective (SLO) which states the deployment option, service tier, hardware, and compute amount."
             ],
             "metadata": {
                 "azdata_cell_guid": "1bdf9b46-44fd-4b09-a088-1d3a3ddfde80"
@@ -9141,4 +9141,4 @@
             }
         }
     ]
-}
+}