Esercizio - Verificare il database SQL di Azure

  • 10 minuti

Ora che si è visto come viene visualizzato SQL di Azure in SQL Server Management Studio (SSMS), è possibile verificare la distribuzione.

Verificare la distribuzione

Dopo aver distribuito un'istanza di SQL, in genere si eseguono alcune query per verificare la distribuzione. In SQL di Azure alcune di queste query sono diverse rispetto a SQL Server. In questo passaggio vengono visualizzate le modifiche apportate a SQL Server, il modo in cui cambiano e le novità.

In questo esercizio vengono illustrate alcune query comuni sulle funzioni di sistema, sulle viste a gestione dinamica (DMV) e sulle viste del catalogo che è possibile usare dopo la distribuzione in SSMS. Si vedrà quali funzionano allo stesso modo in SQL Server, quali funzionano in modo diverso e quali sono nuove in Azure SQL.

  1. Connettersi al server logico del database SQL di Azure in SSMS, se non è già stato fatto.

  2. Fare clic con il pulsante destro del mouse sul AdventureWorksdatabase e selezionare Nuova query.

  3. Controllare la versione distribuita eseguendo la ben nota funzione di sistema @@VERSION.

    SELECT @@VERSION

    Screenshot del risultato della funzione SELECT @@VERSION.

    Il risultato è leggermente diverso da SQL Server. Si può affermare che si tratta di un server di Azure SQL, che non ha versioni. Il database SQL di Azure include le modifiche più aggiornate in linea con la versione più recente di SQL Server. Tuttavia, l'uso della funzione di sistema @@VERSION è un metodo comune per verificare che sia possibile "eseguire una query" su SQL Server.

  4. Determinare il tipo specifico di distribuzione di SQL di Azure, in base al numero restituito:

    • 1: Personal o Desktop Engine
    • 2: Standard
    • 3: Enterprise
    • 4: Express
    • 5: Database SQL
    • 6: SQL Data Warehouse
    • 8: Istanza gestita di SQL

    Eseguire il comando T-SQL seguente per verificare se si ottiene il risultato previsto.

    SELECT SERVERPROPERTY('EngineEdition');

    Screenshot dei risultati per la distribuzione di SQL di Azure.

    Il risultato è 5, che ha senso perché è stato distribuito il database SQL di Azure, non Istanza gestita di SQL o SQL Server Enterprise. Non è presente alcun numero speciale per SQL Server in Macchine virtuali di Azure. Il numero corrisponde all'edizione installata nella macchina virtuale. Personal o Desktop Engine è un'edizione meno recente che non viene più usata con SQL Server.

  5. Ora verranno esaminate le viste del catalogo sys.databases e sys.objects. In genere, si esaminano queste viste per verificare l'installazione e lo stato dei database di sistema e per controllare gli oggetti di sistema nel database.

    SELECT * FROM sys.databases;
SELECT * FROM sys.objects;

    Screenshot che mostra i risultati per sys.databases e sys.objects.

    Nel primo set di risultati i database di sistema msdb, tempdbe model non sono elencati. Sono elencati solo master e il database utente. Il master database su un server logico non è lo stesso del database fisico master installato con SQL Server. In Istanza gestita di SQL di Azure verrà visualizzato il set normale di database di sistema, come per qualsiasi istanza di SQL Server.

    sys.objects è tuttavia simile a una normale istanza di SQL Server. Questo vale per le tabelle di sistema, le tabelle interne e gli oggetti utente per il database AdventureWorksLT di esempio.

  6. Verificare che tutte le utilità di pianificazione siano online e che vengano rilevate le CPU disponibili previste, considerando che la distribuzione è stata eseguita con un modello a due vCore.

    SELECT * FROM sys.dm_os_schedulers where STATUS = 'VISIBLE ONLINE';

    Screenshot che mostra i risultati per sys.dm_os_schedulers.

    Due utilità di pianificazione VISIBLE ONLINE sono quelle che ci si aspetterebbe quando sono disponibili due vCore per l'istanza di SQL Server in cui viene distribuito il database SQL.

  7. Per una distribuzione di SQL Server, in genere è possibile esaminare DMV come sys.dm_process_memory per visualizzare i limiti di CPU, memoria e ruoli di lavoro. Questa vista a gestione dinamica (DMV) non è supportata con il database SQL di Azure, perché l'utente non espone o controlla i dettagli dell'host che supporta il database. È possibile usare la vista DMV sys.dm_user_db_resource_governance per esaminare le capacità e i limiti del database SQL distribuito. È anche possibile usare sys.dm_instance_resource_governance in Istanza gestita di SQL di Azure.

    Eseguire ed esaminare i risultati della query seguente. Confrontare i risultati con il piano tariffario e i limiti documentati per il livello distribuito. slo_name è l'obiettivo del livello di servizio che indica l'opzione di distribuzione, il livello di servizio, l'hardware e la quantità di calcolo. Inoltre, poiché il database SQL di Azure usa oggetti processo di Windows per altri limiti delle risorse, ad esempio la memoria, è possibile usare la vista a gestione dinamica (DMV) sys.dm_os_job_object per visualizzare le risorse disponibili per la distribuzione.

    SELECT * FROM sys.dm_user_db_resource_governance;

    Screenshot dei risultati che mostrano i limiti di governance delle risorse.

  8. Una tecnica comune per analizzare una distribuzione di SQL Server consiste nell'esaminare un elenco di richieste attive. Proprio come per SQL Server, è possibile usare sys.dm_exec_requests per visualizzare le richieste SQL attualmente in esecuzione.

    SELECT * FROM sys.dm_exec_requests;

    Screenshot dei risultati che mostrano dm_exec_requests.

    Usare sys.dm_exec_requests per il database SQL di Azure non è come usarla per SQL Server o per Istanza gestita di SQL. Questa vista a gestione dinamica (DMV) mostra solo le richieste attive correlate al database, incluse le attività in background o le attività in background che non hanno un contesto di database che viene visualizzato come master. Questo comportamento è dovuto alla natura di una distribuzione del database SQL di Azure.