Udostępnij za pośrednictwem

Klasyfikacja obciążeń dla dedykowanej puli SQL w usłudze Azure Synapse Analytics

W tym artykule wyjaśniono proces klasyfikacji obciążeń przypisywania grupy obciążeń i ważności do żądań przychodzących z dedykowanymi pulami SQL w usłudze Azure Synapse.

Klasyfikacja

Klasyfikacja zarządzania obciążeniami umożliwia stosowanie zasad obciążeń do żądań za pomocą przypisywania klas zasobów i ważności.

Chociaż istnieje wiele sposobów klasyfikowania obciążeń magazynowania danych, najprostszą i najbardziej typową klasyfikacją jest ładowanie i wykonywanie zapytań. Dane są ładowane za pomocą instrukcji wstawiania, aktualizowania i usuwania. Tworzysz zapytania do danych za pomocą poleceń SELECT. Rozwiązanie do magazynowania danych często ma politykę obciążenia dla działalności związanej z ładunkiem, taką jak przypisanie wyższej klasy zasobów z większą ilością zasobów. Inna polityka obciążenia może mieć zastosowanie do zapytań, takich jak mniejsze znaczenie w porównaniu z czynnościami ładowania.

Możesz również podklasyfikować obciążenia i wykonywać zapytania o obciążenia. Podklasyfikacja zapewnia większą kontrolę nad obciążeniami. Na przykład obciążenia zapytań mogą składać się z odświeżeń modułów, zapytań pulpitu nawigacyjnego lub zapytań ad hoc. Każde z tych obciążeń zapytań można sklasyfikować przy użyciu różnych klas zasobów lub ustawień ważności. Obciążenie może czerpać korzyści z podklasyfikacji. Duże przekształcenia można przypisać do większych klas zasobów. Wyższy priorytet może służyć do zapewnienia, że kluczowe dane sprzedaży są ładowane przed danymi pogodowymi lub danymi społecznymi.

Nie wszystkie oświadczenia są klasyfikowane, ponieważ nie wymagają zasobów ani nie mają wystarczającego znaczenia, aby wpływać na wykonywanie. DBCC polecenia, BEGIN, COMMITi ROLLBACK TRANSACTION instrukcje nie są klasyfikowane.

Proces klasyfikacji

Klasyfikacja dedykowanej puli SQL jest obecnie osiągana przez przypisanie użytkowników do roli, która ma przypisaną do niej odpowiednią klasę zasobów przy użyciu sp_addrolemember. Możliwość scharakteryzowania żądań jest ograniczona przy użyciu tej funkcji, jeśli wykracza poza sam proces logowania do klasy zasobów. Bogatsza metoda klasyfikacji jest teraz dostępna za pomocą składni CREATE WORKLOAD CLASSIFIER . Dzięki tej składni użytkownicy dedykowanej puli SQL mogą przypisywać znaczenie i ilość zasobów systemowych przypisanych do żądania za pośrednictwem parametru workload_group .

Waga klasyfikacji

W ramach procesu klasyfikacji stosuje się ważenie, aby określić, która grupa robocza jest przypisana. Waga jest następująca:

Parametr klasyfikatora Waga
MEMBERNAME:USER 64
MEMBERNAME:ROLE 32
WLM_LABEL 16
WLM_CONTEXT 8
START_TIME/END_TIME 4

Parametr MEMBERNAME jest obowiązkowy. Jeśli jednak określona nazwa członka odnosi się do użytkownika bazy danych, a nie do roli bazy danych, waga dla użytkownika jest wyższa i dlatego ten klasyfikator jest wybierany.

Jeśli użytkownik jest członkiem wielu ról z różnymi klasami zasobów przypisanymi lub dopasowanymi w wielu klasyfikatorach, użytkownik otrzymuje najwyższe przypisanie klasy zasobów. To zachowanie jest zgodne z zachowaniem istniejącego przypisania klasy zasobów.

Uwaga

Klasyfikowanie zachowań tożsamości zarządzanych różni się między dedykowaną pulą SQL w obszarach roboczych usługi Azure Synapse a autonomiczną dedykowaną pulą SQL (dawniej SQL DW). Chociaż dedykowana pula SQL z autonomiczną tożsamością zarządzaną utrzymuje przypisaną tożsamość, w przypadku obszarów roboczych usługi Azure Synapse tożsamość zarządzana jest uruchamiana jako dbo. Nie można tego zmienić. Rola dbo domyślnie jest klasyfikowana jako smallrc. Utworzenie klasyfikatora dla roli dbo umożliwia przypisywanie żądań do grupy obciążeń innej niż smallrc. Jeśli samo dbo jest zbyt ogólne dla klasyfikacji i ma szersze skutki, rozważ użycie klasyfikacji opartej na etykietach, sesjach lub czasie w połączeniu z klasyfikacją według roli dbo.

Z wyjątkiem smallrc dynamiczne klasy zasobów są implementowane jako wstępnie zdefiniowane role bazy danych. Smallrc nie jest wyświetlana jako rola bazy danych, ale jest domyślną klasą zasobów.

Klasyfikatory systemowe

Klasyfikacja obciążeń ma klasyfikatory obciążeń systemowych. Klasyfikatory systemowe mapują istniejące członkostwa ról klas zasobów na przydziały zasobów klas zasobów o zwykłej ważności. Nie można porzucić klasyfikatorów systemu. Aby wyświetlić klasyfikatory systemowe, możesz uruchomić poniższe zapytanie:

SELECT * FROM sys.workload_management_workload_classifiers where classifier_id <= 12

Mieszanie przydziałów klas zasobów z klasyfikatorami

Klasyfikatory systemowe utworzone w Twoim imieniu zapewniają łatwą ścieżkę migracji do klasyfikacji obciążeń. Użycie mapowań ról klasy zasobów z pierwszeństwem klasyfikacji może prowadzić do błędnej klasyfikacji podczas tworzenia nowych klasyfikatorów o znaczeniu.

Rozważmy następujący scenariusz:

  • Istniejący magazyn danych ma użytkownika bazy danych DBAUser przypisanego do roli w większej klasie zasobów. Przypisanie klasy zasobów zostało wykonane za pomocą polecenia sp_addrolemember.
  • Magazyn danych jest teraz aktualizowany przy użyciu zarządzania obciążeniami.
  • Aby przetestować nową składnię klasyfikacji, rola bazy danych DBARole (którego jest członkiem użytkownik DBAUser) ma utworzony dla nich klasyfikator mapujący na poziom mediumrc oraz duże znaczenie.
  • Gdy DBAUser zaloguje się i uruchomi zapytanie, zapytanie zostanie przypisane do largerc. Ponieważ użytkownik ma pierwszeństwo przed przynależnością do roli.

Aby uprościć rozwiązywanie problemów z błędną klasyfikacją, zalecamy usunięcie mapowań ról klasy zasobów podczas tworzenia klasyfikatorów obciążeń. Poniższy kod zwraca istniejące członkostwa w rolach klas zasobów. Uruchom sp_droprolemember dla każdej nazwy członka zwróconej z odpowiadającej klasy zasobów.

SELECT  r.name AS [Resource Class]
,       m.name AS membername
FROM    sys.database_role_members rm
JOIN    sys.database_principals AS r ON rm.role_principal_id = r.principal_id
JOIN    sys.database_principals AS m ON rm.member_principal_id = m.principal_id
WHERE   r.name IN ('mediumrc','largerc','xlargerc','staticrc10','staticrc20','staticrc30','staticrc40','staticrc50','staticrc60','staticrc70','staticrc80');

--for each row returned run in the previous query
EXEC sp_droprolemember '[Resource Class]', membername;

Powiązana zawartość

  • Last updated on