Cvičení – konfigurace Azure SQL Database
V nástroji Azure Data Studio jste teď viděli Azure Portal, SSMS (SQL Server Management Studio) a soubory SQL Notebook. Pro správu Azure SQL máte k dispozici další nástroje. Mezi nejoblíbenější řešení patří rozhraní Azure CLI a Azure PowerShell. Jsou podobné funkcím. Tato aktivita se zaměřuje na Azure CLI.
Pro dokončení tohoto cvičení můžete použít soubor PowerShell Notebook, který má stejný koncept jako SQL Notebook, ale kódování probíhá v jazyce PowerShell. Poznámkové bloky PowerShellu můžete využít k využití Azure CLI nebo Azure PowerShellu. Tento článek se zaměřuje na příkazy Azure CLI. U obou těchto nástrojů můžete také použít Azure Cloud Shell, což je interaktivní prostředí, se kterým můžete pracovat prostřednictvím prohlížeče na webu Azure Portal.
V tomto cvičení používáme Cloud Shell. Tato služba již obsahuje moduly Azure CLI a Azure PowerShell.
Připojení pomocí Azure Cloud Shellu a Azure CLI
V následujícím příkladu prozkoumáte účinky latence používání různých zásad připojení v Azure SQL.
Spusťte všechny příkazy pomocí Cloud Shellu. Můžete je snadno zkopírovat a pak stisknutím klávesy Shift+Insert vložit do terminálu.
Poznámka:
V PowerShellu pomocí Azure Cloud Shellu můžete použít modul Az PowerShellu nebo Azure CLI. V této aktivitě prozkoumáme Azure CLI, ale podobné příkazy jsou k dispozici pro modul Az PowerShellu.
Pokud se zobrazí výzva, přejděte na shell.azure.com a přihlaste se ke svému účtu Azure.
Nakonfigurujete výchozí skupinu prostředků a logický server Azure SQL Database, abyste je nemuseli zadávat v každém příkazu
az
. Spuštěním následujících příkazů nastavíte určité proměnné. Nahraďte<resource-group>
hodnoty<your-server>
, které jste použili při vytváření instance SQL v předchozím cvičení.resourceGroup="<resource-group>" logical_server="<your-server>" databaseName="AdventureWorks"
Nastavte výchozí hodnoty v Cloud Shellu a určete výchozí skupinu prostředků a logický server Azure SQL Database:
az configure --defaults group=$resourceGroup sql-server=$logical_server
Spuštěním následujícího příkazu potvrďte, že jsou nastavené výchozí hodnoty:
az configure --list-defaults
Spuštěním následujícího příkazu zobrazte všechny databáze na logickém serveru Azure SQL Database:
az sql db list
Seznam databází představuje velké množství informací. Pokud chcete jenom zobrazit konkrétní údaje pro
AdventureWorks
databázi, spusťte následující příkaz:az sql db show --name $databaseName
Spuštěním následujícího příkazu určete velikost a využití databáze:
az sql db list-usages --name $databaseName
Tyto příklady používají příkazy az sql db . K dispozici jsou také příkazy týkající se logického serveru Azure SQL Database. Spadají pod az sql server.
Existují podobné příkazy pro az sql mi a az sql midb. Jedná se o příkazy pro databáze v rámci spravované instance, někdy označované jako spravované databáze.
Podrobné vysvětlení všech dostupných příkazů najdete v dokumentaci k Azure CLI.
Správa zásad připojení pomocí Azure CLI
Jednou z věcí, pro které můžete použít Azure CLI nebo příkazy Azure PowerShellu, je aktualizace zásad připojení. Tato aktualizace je příkladem toho, jak můžete spravovat Azure SQL pomocí nástroje, jako je Azure CLI. V tomto příkladu se podíváte na Azure SQL Database a jeho příkazy pro správu zásad připojení. Implementace je podobná ve službě Azure SQL Managed Instance.
Seznamte se s aktuální zásadou pomocí Azure CLI.
az sql server conn-policy show
Ve výsledcích se dozvíte, že typ připojení je
Default
.Nastavte zásady připojení na hodnotu
Proxy
a určete dobu odezvy.# update policy az sql server conn-policy update --connection-type Proxy # confirm update az sql server conn-policy show
Pokud chcete otestovat dobu odezvy, připojte se pomocí aplikace SSMS. V zařízení otevřete nástroj SSMS a připojte se k databázi. Klikněte pravým tlačítkem na databázi a vyberte Nový dotaz. Vytvořte nový dotaz s následujícím textem a pak vyberte Dotaz>Zahrnout statistiku klienta. Ve výsledcích je nejlepším indikátorem síťové latence položka Wait time on server replies (Čekací doba odezvy serveru). Tento dotaz můžete spustit několikrát, abyste získali dobrý průměr.
-- Proxy SELECT * FROM SalesLT.Product GO 10
Po deseti spuštěních by průměrná doba odezvy serveru dosahovala hodnoty
46.6000
. Výsledky se můžou lišit v závislosti na vašem připojení k internetu. Poznamenejte si čas, který jste zaznamenali.Jak postupovat, když budete chtít všechno přesměrovat pomocí příkazu
Redirect
, abyste se pokusili dosáhnout nižší latence?Pro cokoli, co je mimo Azure, musíte povolit příchozí a odchozí komunikaci na portech v rozsahu 11000 až 11999. Otevření těchto portů se vyžaduje pro
Redirect
zásady připojení.Poznámka:
Tato možnost je pravděpodobně už nakonfigurovaná na vašem místním zařízení. Pokud v dalších krocích dojde k chybám, možná budete muset povolit výše uvedené porty. Další informace najdete v tématu Porty nad rámec 1433 pro ADO.NET 4.5.
Pomocí dvou následujících příkazů aktualizujte zásady připojení a aktualizaci potvrďte.
# update policy az sql server conn-policy update --connection-type Redirect # confirm update az sql server conn-policy show
Pokud chcete otestovat latenci sítě v souvislosti se zásadou
Redirect
, připojte se pomocí SSMS na místním zařízení. Vytvořte nový dotaz pomocí níže uvedeného textu a vyberte možnost Include Client Statistics, aby se do výsledků zahrnuly statistiky klienta. Porovnejte hodnotu Wait time on server replies (Čekací doba odezvy serveru) s výsledky dotazu naProxy
.-- Redirect SELECT * FROM SalesLT.Product GO 10
Po 10 zkušebních verzích může být průměrná doba čekání na odpovědi serveru přibližně
25.8000
, což je téměř polovina zásad připojení proxy serveru. Přesné časování se liší v závislosti na vašem připojení. V porovnání s předchozím testem proxy serveru by se měl výrazně snížit čas.Pomocí následujících příkazů nastavte zásadu zpět na výchozí hodnotu pro další cvičení:
# update policy az sql server conn-policy update --connection-type Default # confirm update az sql server conn-policy show
Přesměrování je rychlejší, protože po počátečním připojení můžete bránu obejít a přejít přímo do databáze. Tento obejití znamená méně segmentů směrování, což má za následek menší latenci. Nižší latence pomáhá bránit vzniku problematických míst, což je důležité zvláště pro „výřečné“ aplikace. V modulu výkonu se dozvíte více o tom, jak zlepšit a optimalizovat výkon.