Monitorowanie zmaterializowanych widoków

Monitoruj kondycję zmaterializowanego widoku w następujący sposób:

• Monitoruj zmaterializowane metryki widoku w Azure Portal.
  • Zmaterializowana metryka MaterializedViewAgeSeconds wieku widoku powinna służyć do monitorowania świeżości widoku. Powinna to być podstawowa metryka do monitorowania.
• Monitoruj właściwość zwróconą IsHealthy z .show materialized-viewelementu .
• Sprawdź błędy przy użyciu polecenia .show materialized-view failures.

Uwaga

Materializacja nigdy nie pomija żadnych danych, nawet jeśli występują stałe błędy. Widok jest zawsze gwarantowany, aby zwrócić najbardziej aktualną migawkę zapytania na podstawie wszystkich rekordów w tabeli źródłowej. Stałe błędy znacznie obniżają wydajność zapytań, ale nie spowodują nieprawidłowych wyników w zapytaniach wyświetlania.

Rozwiązywanie problemów ze zmaterializowanymi widokami w złej kondycji

MaterializedViewHealth Metryka wskazuje, czy zmaterializowany widok jest w dobrej kondycji. Zanim zmaterializowany widok stanie się w złej kondycji, jego wiek, zanotowany przez MaterializedViewAgeSeconds metrykę, stopniowo wzrasta.

Zmaterializowany widok może stać się w złej kondycji z dowolnego lub z następujących powodów:

• Proces materializacji kończy się niepowodzeniem. Metryka MaterializedViewResult i .show materialized-view failures polecenie może pomóc zidentyfikować główną przyczynę błędu.
• System mógł automatycznie wyłączyć zmaterializowany widok z powodu zmian w tabeli źródłowej. Możesz sprawdzić, czy widok jest wyłączony, sprawdzając kolumnę zwróconą IsEnabled z .show materialized-view polecenia . Zobacz więcej szczegółów w zmaterializowanych ograniczeniach widoków i znanych problemach
• Klaster nie ma wystarczającej pojemności, aby zmaterializować wszystkie przychodzące dane na czas. W takim przypadku mogą nie wystąpić błędy podczas wykonywania. Jednak wiek widoku stopniowo wzrasta, ponieważ nie jest w stanie nadążyć za współczynnikiem pozyskiwania. Może istnieć kilka głównych przyczyn tej sytuacji:
  • W klastrze jest więcej zmaterializowanych widoków, a klaster nie ma wystarczającej pojemności do uruchamiania wszystkich widoków. Zobacz zmaterializowane zasady pojemności widoku , aby zmienić ustawienia domyślne liczby zmaterializowanych widoków wykonywanych współbieżnie.
  • Materializacja jest niska, ponieważ istnieje zbyt wiele rekordów do zaktualizowania w każdym cyklu materializacji. Aby dowiedzieć się więcej o tym, dlaczego ma to wpływ na wydajność widoku, zobacz , jak działają zmaterializowane widoki. Liczba zakresów, które wymagają aktualizacji w każdym cyklu, jest podana w metryce MaterializedViewExtentsRebuild .

Zmaterializowana metrykaViewResult

MaterializedViewResult Metryka zawiera informacje o wyniku cyklu materializacji i może służyć do identyfikowania problemów w zmaterializowanym stanie kondycji widoku. Metryka zawiera wymiar Database i i MaterializedViewNameResult .

Wymiar Result może mieć jedną z następujących wartości:

• Powodzenie: materializacja zakończyła się pomyślnie.

• SourceTableNotFound: Tabela źródłowa widoku materializacji została porzucona. Zmaterializowany widok jest automatycznie wyłączony w wyniku.

• SourceTableSchemaChange: schemat tabeli źródłowej zmienił się w sposób, który nie jest zgodny z zmaterializowaną definicją widoku (zmaterializowane zapytanie widoku nie jest zgodne ze zmaterializowanym schematem widoku). Zmaterializowany widok jest automatycznie wyłączony w wyniku.

• InsufficientCapacity: klaster nie ma wystarczającej pojemności, aby zmaterializować zmaterializowany widok. Może to wskazywać na brak pojemności pozyskiwania lub brak zmaterializowanej pojemności widoków. Niewystarczające błędy pojemności mogą być przejściowe, ale jeśli powtarzają się często, zalecamy skalowanie klastra lub zwiększenie odpowiedniej pojemności w zasadach.

• Niewystarczające źródła: Klaster nie ma wystarczających zasobów (procesora CPU/pamięci), aby zmaterializować zmaterializowany widok. Ten błąd może być przejściowy, ale jeśli powtarza się, spróbuj przeskalować klaster w górę lub wyjść.

  • Jeśli proces materializacji osiągnie limity pamięci, limity grup obciążeń widoków $materialized można zwiększyć w celu obsługi większej ilości pamięci lub procesora CPU w procesie materializacji do użycia.

  Na przykład następujące polecenie spowoduje zmianę zmaterializowanej grupy obciążeń widoków w celu użycia maksymalnej liczby 64 gigabajtów (GB) pamięci na węzeł podczas materializacji (wartość domyślna to 15 GB):

  .alter-merge workload_group ['$materialized-views'] ```
  {
    "RequestLimitsPolicy": {
      "MaxMemoryPerQueryPerNode": {
        "Value": 68719241216
      }
    }
  } ```
  

  Uwaga

  MaxMemoryPerQueryPerNode nie można ustawić na więcej niż 50% całkowitej pamięci każdego węzła.

Zmaterializowane widoki w kolejnych bazach danych

Zmaterializowane widoki można zdefiniować w kolejnych bazach danych. Jednak monitorowanie tych zmaterializowanych widoków powinno opierać się na bazie danych lidera, w której zdefiniowany jest zmaterializowany widok. W szczególności:

• Metryki związane z zmaterializowanym wykonywaniem widoku (MaterializedViewResult, MaterializedViewExtentsRebuild) są obecne tylko w bazie danych lidera. Metryki związane z monitorowaniem (MaterializedViewAgeSeconds, MaterializedViewHealth, MaterializedViewRecordsInDelta) będą również wyświetlane w kolejnych bazach danych.
• Polecenie .show materialized-view failures działa tylko w bazie danych lidera.

Śledzenie użycia zasobów

Zmaterializowane użycie zasobów widoków: zasoby używane przez zmaterializowany proces materializacji widoków można śledzić za pomocą .show commands-and-queries polecenia . Przefiltruj rekordy dla określonego widoku, używając następujących wartości (zastąp DatabaseName i ViewName):

.show commands-and-queries 
| where Database  == "DatabaseName" and ClientActivityId startswith "DN.MaterializedViews;ViewName;"