W tym artykule przyjęto założenie, że zostały już opracowane zalecenia doradcy bazy danych bazy danych Azure SQL izalecenia dotyczące automatycznego dostrajania bazy danych Azure SQL Database, jeśli ma to zastosowanie. Przyjęto również założenie, że zapoznano się z omówieniem monitorowania i dostrajania oraz powiązanych artykułów związanych z rozwiązywaniem problemów z wydajnością. Ponadto w tym artykule założono, że nie masz zasobów procesora CPU, który może zostać rozwiązany, zwiększając rozmiar obliczeniowy lub warstwę usług, aby zapewnić więcej zasobów do bazy danych.
W tradycyjnych SQL Server lokalnych proces planowania pojemności początkowej jest często oddzielony od procesu uruchamiania aplikacji w środowisku produkcyjnym. Licencje sprzętu i produktu są najpierw kupowane, a dostrajanie wydajności odbywa się później. Jeśli używasz Azure SQL, warto przeplatać proces uruchamiania aplikacji i dostrajać go. Dzięki modelowi płacenia za pojemność na żądanie możesz dostosować aplikację do użycia minimalnych zasobów potrzebnych teraz, zamiast nadmiernej aprowizacji sprzętu na podstawie odgadnięcia przyszłych planów wzrostu aplikacji, które często są niepoprawne. Niektórzy klienci mogą nie dostroić aplikacji, a zamiast tego zdecydować się na nadmierną aprowizację zasobów sprzętowych. Takie podejście może być dobrym pomysłem, jeśli nie chcesz zmieniać aplikacji klucza w okresie zajętości. Jednak dostrajanie aplikacji może zminimalizować wymagania dotyczące zasobów i obniżyć miesięczne rachunki podczas korzystania z warstw usług w usłudze Azure SQL Database i Azure SQL Managed Instance.
Chociaż Azure SQL Bazy danych i Azure SQL Managed Instance warstwy usług zostały zaprojektowane w celu zwiększenia stabilności wydajności i przewidywalności aplikacji, niektóre najlepsze rozwiązania mogą pomóc w dostrojeniu aplikacji, aby lepiej wykorzystać zasoby o rozmiarze obliczeniowym. Mimo że wiele aplikacji ma znaczne wzrosty wydajności, po prostu przełączając się na wyższy rozmiar obliczeniowy lub warstwę usług, niektóre aplikacje wymagają dodatkowego dostrajania, aby korzystać z wyższego poziomu usług. Aby zwiększyć wydajność, rozważ dodatkowe dostrajanie aplikacji dla aplikacji, które mają następujące cechy:
Aplikacje, które mają nieoptymalny projekt dostępu do danych
Aplikacje, które mają z natury problemy ze współbieżnością dostępu do danych, na przykład zakleszczenia, mogą nie korzystać z większego rozmiaru obliczeniowego. Rozważ zmniejszenie liczby rund względem bazy danych przez buforowanie danych po stronie klienta przy użyciu technologii azure usługa buforowania lub innej technologii buforowania. Zobacz Buforowanie warstwy aplikacji.
Aby zapobiec ponownemu zakleszczeniom w usłudze Azure SQL Database, zobacz Analizowanie i zapobieganie zakleszczeniom w usłudze Azure SQL Database. Aby uzyskać Azure SQL Managed Instance, zapoznaj się z przewodnikiem zakleszczeniatransakcji blokowania i przechowywania wersji wierszy.
Dostrajanie bazy danych
W tej sekcji przyjrzymy się niektórym technikom, za pomocą których można dostosować bazę danych, aby uzyskać najlepszą wydajność aplikacji i uruchomić ją przy najniższym możliwym rozmiarze obliczeniowym. Niektóre z tych technik są zgodne z tradycyjnymi SQL Server dostrajaniem najlepszych rozwiązań, ale inne są specyficzne dla Azure SQL Database i Azure SQL Managed Instance. W niektórych przypadkach możesz zbadać używane zasoby bazy danych, aby znaleźć obszary, aby jeszcze bardziej dostosować i rozszerzyć tradycyjne techniki SQL Server do pracy w usłudze Azure SQL Database i Azure SQL Managed Instance.
Identyfikowanie i dodawanie brakujących indeksów
Typowy problem w wydajności bazy danych OLTP odnosi się do projektu fizycznej bazy danych. Często schematy baz danych są projektowane i dostarczane bez testowania na dużą skalę (w obciążeniu lub woluminie danych). Niestety wydajność planu zapytania może być akceptowalna na małą skalę, ale znacznie obniża wydajność woluminów danych na poziomie produkcyjnym. Najczęstszym źródłem tego problemu jest brak odpowiednich indeksów w celu spełnienia filtrów lub innych ograniczeń w zapytaniu. Często brakujące manifesty indeksów są skanowane w postaci tabeli, gdy wyszukiwanie indeksu może wystarczyć.
W tym przykładzie wybrany plan zapytania używa skanowania, gdy wyszukiwanie wystarczy:
DROP TABLE dbo. missingindex;CREATE TABLE dbo. missingindex (col1 INT IDENTITY PRIMARY KEY, col2 INT);DECLARE @a int = 0;SET NOCOUNT ON;BEGIN TRANSACTIONWHILE @a < 20000BEGININSERT INTO dbo. missingindex(col2) VALUES (@a);SET @a += 1;ENDCOMMIT TRANSACTION;GOSELECT m1. col1FROM dbo. missingindex m1 INNER JOIN dbo. missingindex m2 ON(m1. col1=m2. col1)WHERE m1. col2 = 4;
Azure SQL Baza danych i Azure SQL Managed Instance mogą pomóc w znalezieniu i naprawieniu typowych brakujących warunków indeksu. Dynamiczne widoki zarządzania wbudowane w bazę danych Azure SQL i Azure SQL Managed Instance przyjrzeć się kompilacjom zapytań, w których indeks znacznie obniży szacowany koszt uruchamiania zapytania. Podczas wykonywania zapytań aparat bazy danych śledzi częstotliwość wykonywania każdego planu zapytania i śledzi szacowaną lukę między wykonywaniem planu zapytania a wyobrażonym planem, w którym istniał ten indeks. Za pomocą tych widoków DMV można szybko odgadnąć, które zmiany projektu fizycznej bazy danych mogą zwiększyć całkowity koszt obciążenia bazy danych i rzeczywistego obciążenia.
To zapytanie umożliwia ocenę potencjalnych brakujących indeksów:
SELECTCONVERT (varchar, getdate(), 126) AS runtime, mig. index_group_handle, mid. index_handle, CONVERT (decimal (28, 1), migs. avg_total_user_cost * migs. avg_user_impact *(migs. user_seeks + migs. user_scans)) AS improvement_measure, 'CREATE INDEX missing_index_' + CONVERT (varchar, mig. index_group_handle) + '_' +CONVERT (varchar, mid. index_handle) + ' ON ' + mid. statement + '(' + ISNULL (mid. equality_columns, '')+ CASE WHEN mid. equality_columns IS NOT NULLAND mid. inequality_columns IS NOT NULLTHEN ', ' ELSE '' END + ISNULL (mid. inequality_columns, '') + ')'+ ISNULL (' INCLUDE (' + mid. included_columns + ')', '') AS create_index_statement, migs. *, mid. database_id, mid. [object_id]FROM sys. dm_db_missing_index_groups AS migINNER JOIN sys. dm_db_missing_index_group_stats AS migsON migs. group_handle = mig. index_group_handleINNER JOIN sys. dm_db_missing_index_details AS midON mig. index_handle = mid. index_handleORDER BY migs. avg_user_impact * (migs. user_scans) DESCW tym przykładzie zapytanie spowodowało następującą sugestię:
CREATE INDEX missing_index_5006_5005 ON [dbo]. [missingindex] ([col2])Po jego utworzeniu ta sama instrukcja SELECT wybiera inny plan, który używa wyszukiwania zamiast skanowania, a następnie wykonuje plan wydajniej:
Kluczową analizą jest to, że pojemność we/wy udostępnionego systemu towarowego jest bardziej ograniczona niż pojemność dedykowanego komputera serwera. Istnieje premia do zminimalizowania niepotrzebnych operacji we/wy, aby maksymalnie wykorzystać system w zasobach każdego rozmiaru obliczeniowego warstw usług. Odpowiednie opcje projektowania fizycznej bazy danych mogą znacznie poprawić opóźnienie poszczególnych zapytań, zwiększyć przepływność współbieżnych żądań obsługiwanych na jednostkę skalowania i zminimalizować koszty wymagane do spełnienia zapytania.
Aby uzyskać więcej informacji na temat dostrajania indeksów przy użyciu brakujących żądań indeksów, zobacz Tune nonclustered indexes with missing index suggestions (Dostrajanie indeksów bez sugestii dotyczących indeksu).
Dostrajanie zapytań i podpowiedzi
Optymalizator zapytań w usłudze Azure SQL Database i Azure SQL Managed Instance jest podobny do tradycyjnego optymalizatora zapytań SQL Server. Większość najlepszych rozwiązań dotyczących dostrajania zapytań i zrozumienia ograniczeń modelu rozumowania dla optymalizatora zapytań dotyczy również Azure SQL Database i Azure SQL Managed Instance. Jeśli dostrajasz zapytania w usłudze Azure SQL Database i Azure SQL Managed Instance, możesz uzyskać dodatkową zaletę zmniejszenia zapotrzebowania na zasoby zagregowane. Aplikacja może być w stanie uruchomić przy niższych kosztach niż odpowiednik nie dostrojony, ponieważ może działać w mniejszym rozmiarze obliczeniowym.
Przykładem, który jest typowy w SQL Server i który ma również zastosowanie do Azure SQL Database i Azure SQL Managed Instance jest sposób, w jaki optymalizator zapytań "sniffs" parametrów. Podczas kompilacji optymalizator zapytań ocenia bieżącą wartość parametru, aby określić, czy może wygenerować bardziej optymalny plan zapytania. Chociaż ta strategia często może prowadzić do planu zapytania, który jest znacznie szybszy niż plan skompilowany bez znanych wartości parametrów, obecnie działa on niedoskońwie zarówno w SQL Server, w usłudze Azure SQL Database, jak i Azure SQL Managed Instance. Czasami parametr nie jest wąchany, a czasami parametr jest wąchany, ale wygenerowany plan jest nieoptymalny dla pełnego zestawu wartości parametrów w obciążeniu. Firma Microsoft zawiera wskazówki dotyczące zapytań (dyrektywy), dzięki czemu można określić intencję bardziej celowo i zastąpić domyślne zachowanie wąchania parametrów. Często, jeśli używasz wskazówek, możesz naprawić przypadki, w których domyślne SQL Server, baza danych Azure SQL i zachowanie Azure SQL Managed Instance jest niedoskonałe dla określonego obciążenia klienta.
W następnym przykładzie pokazano, jak procesor zapytań może wygenerować plan, który jest nieoptymalny zarówno dla wymagań dotyczących wydajności, jak i zasobów. W tym przykładzie pokazano również, że jeśli używasz wskazówki dotyczącej zapytania, możesz zmniejszyć czas wykonywania zapytań i wymagania dotyczące zasobów dla bazy danych:
DROP TABLE psptest1;CREATE TABLE psptest1(col1 int primary key identity, col2 int, col3 binary(200));INSERT INTO psptest1(col2) values (1);INSERT INTO psptest1(col2) values (@a);COMMIT TRANSACTIONCREATE INDEX i1 on psptest1(col2);CREATE PROCEDURE psp1 (@param1 int)ASINSERT INTO t1 SELECT * FROM psptest1WHERE col2 = @param1ORDER BY col2;CREATE PROCEDURE psp2 (@param2 int)INSERT INTO t1 SELECT * FROM psptest1 WHERE col2 = @param2ORDER BY col2OPTION (OPTIMIZE FOR (@param2 UNKNOWN))CREATE TABLE t1 (col1 int primary key, col2 int, col3 binary(200));Kod konfiguracji tworzy tabelę, która ma niesymetryczny rozkład danych. Optymalny plan zapytania różni się w zależności od wybranego parametru. Niestety zachowanie buforowania planu nie zawsze rekompiluje zapytanie na podstawie najpopularniejszej wartości parametru. Dlatego można buforować nieoptymalny plan i używać go dla wielu wartości, nawet jeśli inny plan może być lepszym wyborem średnio. Następnie plan zapytania tworzy dwie procedury składowane, które są identyczne, z wyjątkiem tego, że jeden ma specjalną wskazówkę zapytania.
-- Prime Procedure Cache with scan planEXEC psp1 @param1=1;TRUNCATE TABLE t1;-- Iterate multiple times to show the performance differenceDECLARE @i int = 0;WHILE @i < 1000EXEC psp1 @param1=2;SET @i += 1;Zalecamy odczekać co najmniej 10 minut przed rozpoczęciem części 2 przykładu, aby wyniki zostały odrębne w wynikowych danych telemetrycznych.
EXEC psp2 @param2=1;EXEC psp2 @param2=2;Każda część tego przykładu próbuje uruchomić sparametryzowaną instrukcję insert 1000 razy (aby wygenerować wystarczające obciążenie do użycia jako zestaw danych testowych). Po wykonaniu procedur składowanych procesor zapytań sprawdza wartość parametru przekazywaną do procedury podczas pierwszej kompilacji (parametr "sniffing"). Procesor buforuje wynikowy plan i używa go do późniejszego wywołania, nawet jeśli wartość parametru jest inna. Optymalny plan może nie być używany we wszystkich przypadkach. Czasami należy kierować optymalizatorem, aby wybrać plan, który jest lepszy dla średniej wielkości liter, a nie konkretny przypadek od momentu pierwszego skompilowania zapytania. W tym przykładzie początkowy plan generuje plan "skanowania", który odczytuje wszystkie wiersze, aby znaleźć każdą wartość zgodną z parametrem:
Ponieważ wykonaliśmy procedurę przy użyciu wartości 1, wynikowy plan był optymalny dla wartości 1, ale był nieoptymalny dla wszystkich innych wartości w tabeli. Wynik prawdopodobnie nie jest odpowiedni, jeśli chcesz wybrać każdy plan losowo, ponieważ plan działa wolniej i używa większej ilości zasobów.
Jeśli uruchomisz test z ustawioną wartością SET STATISTICS IOON, w tym przykładzie wykonano pracę skanowania logicznego w tle. Widać, że w planie wykonano 1148 odczytów (co jest nieefektywne, jeśli średni przypadek ma zwrócić tylko jeden wiersz):
Druga część przykładu używa wskazówki zapytania, aby poinformować optymalizatora o użyciu określonej wartości podczas procesu kompilacji. W takim przypadku wymusza na procesorze zapytań ignorowanie wartości przekazanej jako parametru, a zamiast tego przyjmuje wartość UNKNOWN. Odnosi się to do wartości, która ma średnią częstotliwość w tabeli (ignorując niesymetryczność). Wynikowy plan jest planem opartym na poszukiwaniu, który jest szybszy i zużywa średnio mniej zasobów niż plan w części 1 tego przykładu:
Efekt można zobaczyć w tabeli sys. resource_stats (występuje opóźnienie od czasu wykonania testu i gdy dane wypełniają tabelę). W tym przykładzie część 1 wykonana w przedziale czasu 22:25:00 i część 2 wykonana o godzinie 22:35:00. Wcześniejsze przedziały czasu używały większej liczby zasobów w tym przedziale czasu niż w późniejszym przedziale czasu (ze względu na ulepszenia wydajności planu).
SELECT TOP 1000 *FROM sys. resource_statsWHERE database_name = 'resource1'ORDER BY start_time DESCUwaga
Mimo że wolumin w tym przykładzie jest celowo mały, wpływ nieoptymalnych parametrów może być znaczący, zwłaszcza w przypadku większych baz danych. Różnica, w skrajnych przypadkach, może być między sekundami w przypadku szybkich przypadków i godzin w przypadku powolnych przypadków.
Możesz sprawdzić sys. resource_stats, aby określić, czy zasób testu używa więcej lub mniej zasobów niż inny test. Podczas porównywania danych rozdziel czas testów, aby nie były one w tym samym 5-minutowym oknie w widoku sys. resource_stats. Celem ćwiczenia jest zminimalizowanie całkowitej ilości używanych zasobów, a nie zminimalizowanie szczytowych zasobów. Ogólnie rzecz biorąc, optymalizacja fragmentu kodu pod kątem opóźnienia zmniejsza również zużycie zasobów. Upewnij się, że zmiany wprowadzone w aplikacji są niezbędne i że zmiany nie wpływają negatywnie na środowisko klienta dla kogoś, kto może używać wskazówek dotyczących zapytań w aplikacji.
Jeśli obciążenie ma zestaw powtarzających się zapytań, często warto przechwycić i zweryfikować optymalność wyborów planu, ponieważ obsługuje minimalną jednostkę rozmiaru zasobów wymaganą do hostowania bazy danych. Po zweryfikowaniu tego, od czasu do czasu ponownie przejmij plany, aby pomóc upewnić się, że nie uległy pogorszeniu. Więcej informacji na temat wskazówek dotyczących zapytań (Transact-SQL) można dowiedzieć się więcej.
Bardzo duże architektury baz danych
Przed wydaniem warstwy usługi Hiperskala dla pojedynczych baz danych w usłudze Azure SQL Database klienci korzystający z limitów pojemności dla poszczególnych baz danych. Te limity pojemności nadal istnieją dla baz danych w puli w elastycznych pulach bazy danych Azure SQL Database i bazach danych wystąpień w Azure SQL wystąpieniach zarządzanych. W poniższych dwóch sekcjach omówiono dwie opcje rozwiązywania problemów z bardzo dużymi bazami danych w usłudze Azure SQL Database i Azure SQL Managed Instance, gdy nie można użyć warstwy usługi Hiperskala.
Fragmentowanie między bazami danych
Ponieważ Azure SQL Database i Azure SQL Managed Instance działają na sprzęcie towarowym, limity pojemności dla pojedynczej bazy danych są niższe niż w przypadku tradycyjnej instalacji lokalnej SQL Server. Niektórzy klienci używają technik fragmentowania w celu rozłożenia operacji bazy danych na wiele baz danych, gdy operacje nie mieszczą się w granicach pojedynczej bazy danych w usłudze Azure SQL Database i Azure SQL Managed Instance. Większość klientów korzystających z technik fragmentowania w usłudze Azure SQL Database i Azure SQL Managed Instance podzielić swoje dane na jeden wymiar w wielu bazach danych. W przypadku tego podejścia należy zrozumieć, że aplikacje OLTP często wykonują transakcje, które mają zastosowanie tylko do jednego wiersza lub do małej grupy wierszy w schemacie.
Jeśli na przykład baza danych ma nazwę klienta, zamówienie i szczegóły zamówienia (na przykład tradycyjna przykładowa baza danych Northwind, która jest dostarczana z SQL Server), możesz podzielić te dane na wiele baz danych, grupując klienta z powiązanymi informacjami o zamówieniu i szczegółach zamówienia. Możesz zagwarantować, że dane klienta pozostają w pojedynczej bazie danych. Aplikacja dzieliłaby różnych klientów między bazy danych, efektywnie rozkładając obciążenie na wiele baz danych. Dzięki fragmentowaniu klienci nie tylko mogą uniknąć maksymalnego limitu rozmiaru bazy danych, ale także Azure SQL Database i Azure SQL Managed Instance mogą przetwarzać obciążenia, które są znacznie większe niż limity różnych rozmiarów obliczeniowych, o ile każda pojedyncza baza danych mieści się w limitach warstwy usług.
Chociaż fragmentowanie bazy danych nie zmniejsza pojemności zagregowanej zasobów dla rozwiązania, jest wysoce skuteczne w obsłudze bardzo dużych rozwiązań, które są rozłożone na wiele baz danych. Każda baza danych może działać w innym rozmiarze obliczeniowym, aby obsługiwać bardzo duże, "skuteczne" bazy danych z wysokimi wymaganiami dotyczącymi zasobów.
Partycjonowanie funkcjonalne
Użytkownicy często łączą wiele funkcji w pojedynczej bazie danych. Jeśli na przykład aplikacja ma logikę zarządzania spisem dla sklepu, ta baza danych może mieć logikę skojarzoną ze spisem, śledzenie zamówień zakupu, procedur składowanych i zindeksowanych lub zmaterializowanych widoków, które zarządzają raportowaniem zakończenia miesiąca. Ta technika ułatwia administrowanie bazą danych na potrzeby operacji, takich jak tworzenie kopii zapasowych, ale także wymaga rozmiaru sprzętu w celu obsługi szczytowego obciążenia we wszystkich funkcjach aplikacji.
Jeśli używasz architektury skalowanej w poziomie w usłudze Azure SQL Database i Azure SQL Managed Instance, warto podzielić różne funkcje aplikacji na różne bazy danych. Korzystając z tej techniki, każda aplikacja jest skalowana niezależnie. Gdy aplikacja staje się bardziej ruchliwa (a obciążenie bazy danych wzrasta), administrator może wybrać niezależne rozmiary obliczeniowe dla każdej funkcji w aplikacji. W przypadku tej architektury aplikacja może być większa niż jedna maszyna towarowa, ponieważ obciążenie jest rozłożone na wiele maszyn.
Zapytania wsadowe
W przypadku aplikacji, które uzyskują dostęp do danych przy użyciu często używanych zapytań ad hoc, znaczna ilość czasu odpowiedzi jest poświęcana na komunikację sieciową między warstwą aplikacji a warstwą bazy danych. Nawet jeśli zarówno aplikacja, jak i baza danych znajdują się w tym samym centrum danych, opóźnienie sieci między nimi może być powiększone przez dużą liczbę operacji dostępu do danych. Aby zmniejszyć liczbę rund sieci dla operacji dostępu do danych, rozważ użycie opcji wsadowania zapytań ad hoc lub skompilowania ich jako procedur składowanych. W przypadku wsadowania zapytań ad hoc można wysłać wiele zapytań jako jedną dużą partię w jednej podróży do bazy danych. W przypadku kompilowania zapytań ad hoc w procedurze składowanej można osiągnąć taki sam wynik, jak w przypadku ich wsadowania. Użycie procedury składowanej daje również korzyści z zwiększenia szans na buforowanie planów zapytań w bazie danych, dzięki czemu można ponownie użyć procedury składowanej.
Niektóre aplikacje intensywnie korzystają z zapisu. Czasami można zmniejszyć łączne obciążenie operacji we/wy w bazie danych, biorąc pod uwagę sposób wsadowego zapisywania wsadowego. Często jest to tak proste, jak używanie jawnych transakcji zamiast transakcji automatycznego zatwierdzania w procedurach składowanych i partiach ad hoc. Aby zapoznać się z oceną różnych technik, których można użyć, zobacz Techniki batching dla aplikacji baz danych na platformie Azure. Eksperymentuj z własnym obciążeniem, aby znaleźć odpowiedni model do przetwarzania wsadowego. Pamiętaj, aby zrozumieć, że model może mieć nieco inne gwarancje spójności transakcyjnej. Znalezienie odpowiedniego obciążenia, które minimalizuje użycie zasobów, wymaga znalezienia odpowiedniej kombinacji kompromisów spójności i wydajności.
Buforowanie warstwy aplikacji
Niektóre aplikacje bazy danych mają obciążenia o dużym obciążeniu odczytu. Warstwy buforowania mogą zmniejszyć obciążenie bazy danych i potencjalnie zmniejszyć rozmiar obliczeniowy wymagany do obsługi bazy danych przy użyciu usługi Azure SQL Database i Azure SQL Managed Instance. W przypadku Azure Cache for Redis, jeśli masz obciążenie z dużym obciążeniem do odczytu, możesz odczytać dane raz (lub być może raz na maszynę warstwy aplikacji, w zależności od tego, jak jest ona skonfigurowana), a następnie przechowywać te dane poza bazą danych. Jest to sposób zmniejszenia obciążenia bazy danych (procesora CPU i operacji we/wy odczytu), ale istnieje wpływ na spójność transakcyjną, ponieważ dane odczytywane z pamięci podręcznej mogą nie być zsynchronizowane z danymi w bazie danych. Chociaż w wielu aplikacjach akceptowalny jest pewien poziom niespójności, nie jest to prawdziwe dla wszystkich obciążeń. Przed zaimplementowaniem strategii buforowania warstwy aplikacji należy w pełni zrozumieć wszelkie wymagania aplikacji.
Uzyskiwanie wskazówek dotyczących konfiguracji i projektowania
Jeśli używasz usługi Azure SQL Database, możesz wykonać skrypt języka T-SQL typu open source w celu poprawy konfiguracji i projektowania bazy danych w usłudze Azure SQL DB. Skrypt przeanalizuje bazę danych na żądanie i przekaże wskazówki dotyczące poprawy wydajności i kondycji bazy danych. Niektóre wskazówki sugerują zmiany konfiguracji i operacyjne w oparciu o najlepsze rozwiązania, podczas gdy inne porady zalecają zmiany projektowe odpowiednie dla obciążenia, takie jak włączanie zaawansowanych funkcji aparatu bazy danych.
Aby dowiedzieć się więcej o skrypcie i rozpocząć pracę, odwiedź stronę typu wiki Azure SQL Porady.
Następne kroki
Dowiedz się więcej o modelu zakupów opartym na jednostkach DTUDowiedz się więcej o modelu zakupów opartym na rdzeniach wirtualnychPrzeczytaj co to jest elastyczna pula platformy Azure? Odnajdywanie , kiedy należy wziąć pod uwagę elastyczną pulęPrzeczytaj o monitorowaniu Microsoft Azure SQL Database i wydajności Azure SQL Managed Instance przy użyciu dynamicznych widoków zarządzaniaDowiedz się, jak diagnozować i rozwiązywać problemy z wysokim użyciem procesora CPU w usłudze Azure SQL DatabaseDostrajanie indeksów nieklastrowanych z brakującymi sugestiami indeksuWideo: Ładowanie danych najlepszych rozwiązań dotyczących bazy danych Azure SQL
