Zmaterializowane zasady widoków

Ten artykuł zawiera informacje o zasadach, które można ustawić dla zmaterializowanych widoków.

Zasady przechowywania i buforowania

Zmaterializowany widok ma zasady przechowywania i zasady buforowania. Zmaterializowany widok domyślnie uzyskuje zasady przechowywania i buforowania bazy danych. Te zasady można zmienić przy użyciu poleceń zarządzania zasadami przechowywania lub poleceń zarządzania zasadami buforowania.

Obie zasady są stosowane tylko w zmaterializowanej części zmaterializowanego widoku. Aby uzyskać wyjaśnienie różnic między zmaterializowaną częścią a częścią różnicową, zobacz jak działają zmaterializowane widoki. Jeśli na przykład zasady buforowania zmaterializowanego widoku są ustawione na wartość 7d, ale zasady buforowania tabeli źródłowej są ustawione na wartość 0d, podczas wykonywania zapytań dotyczących zmaterializowanego widoku nadal mogą występować błędy dysku. To zachowanie występuje, ponieważ tabela źródłowa (część delty) również uczestniczy w zapytaniu.

Zasady przechowywania zmaterializowanego widoku nie są powiązane z zasadami przechowywania tabeli źródłowej. Zasady przechowywania tabeli źródłowej mogą być krótsze niż zasady przechowywania zmaterializowanego widoku, jeśli rekordy źródłowe są wymagane przez krótszy okres. Zalecamy stosowanie minimalnych zasad przechowywania wynoszących co najmniej kilka dni i możliwość odzyskiwania ustawiona na wartość true w tabeli źródłowej. To ustawienie umożliwia szybkie odzyskiwanie w przypadku błędów i do celów diagnostycznych.

Uwaga

Zasady zerowego przechowywania w tabeli źródłowej nie są obsługiwane.

Zasady przechowywania i buforowania zależą od czasu utworzenia zakresu. Ostatnia aktualizacja rekordu określa czas tworzenia zakresu dla zmaterializowanego widoku.

Uwaga

Proces materializacji próbuje zminimalizować ilość aktualizacji zmaterializowanej części widoku. W przypadkach, gdy rekord nie musi być aktualizowany w widoku, nie zostanie zaktualizowany. Na przykład gdy zmaterializowany widok jest take_any(*) agregacją, nowe rekordy tych samych kluczy grupowania według kluczy nie zostaną ponownie pozyskane do widoku, a zatem zasady przechowywania będą pozyskiwane najwcześniej.

Zasady partycjonowania

Zasady partycjonowania można zastosować w zmaterializowanym widoku. Zalecamy skonfigurowanie zasad partycjonowania w zmaterializowanym widoku tylko wtedy, gdy większość lub wszystkie zapytania widoku są filtrowane według jednego z zmaterializowanych kluczy widoku grupowania. Ta sytuacja jest powszechna w rozwiązaniach z wieloma dzierżawami, gdzie jednym z zmaterializowanych kluczy widoku grupowania jest identyfikator dzierżawy (na przykład tenantId, customerId). Aby uzyskać więcej informacji, zobacz pierwszy przypadek użycia opisany na stronie scenariuszy obsługiwanych przez zasady partycjonowania .

Aby uzyskać polecenia umożliwiające zmianę zmaterializowanego widoku zasad partycjonowania, zobacz partycjonowanie poleceń zasad.

Dodanie zasad partycjonowania w zmaterializowanym widoku zwiększa liczbę zakresów w zmaterializowanym widoku i tworzy więcej "pracy" dla procesu materializacji. Aby uzyskać więcej informacji na temat przyczyny tego zachowania, zobacz proces ponownego kompilowania zakresów wymieniony w sposobie działania zmaterializowanych widoków.

Zasady zabezpieczeń na poziomie wiersza

Zabezpieczenia na poziomie wiersza można zastosować w zmaterializowanym widoku z kilkoma ograniczeniami:

  • Zasady można stosować tylko do zmaterializowanych widoków za pomocą funkcji agregacji arg_max()/arg_min()/take_any() lub gdy zapytanie zabezpieczeń na poziomie wiersza odwołuje się do grupy według kluczy agregacji zmaterializowanego widoku.
  • Zasady są stosowane tylko do zmaterializowanej części widoku.
    • Jeśli te same zasady zabezpieczeń na poziomie wiersza nie są zdefiniowane w tabeli źródłowej zmaterializowanego widoku, zapytanie dotyczące zmaterializowanego widoku może zwracać rekordy, które powinny być ukryte przez zasady. Dzieje się tak, ponieważ wykonywanie zapytań względem zmaterializowanego widoku wykonuje również zapytania dotyczące tabeli źródłowej.
    • Zalecamy zdefiniowanie tych samych zasad zabezpieczeń na poziomie wiersza zarówno w tabeli źródłowej, jak i zmaterializowanym widoku, jeśli widok jest arg_max() lub arg_min()/take_any().
  • Podczas definiowania zasad zabezpieczeń na poziomie wiersza w tabeli źródłowej arg_max() lub arg_min()/take_any() zmaterializowanego widoku polecenie kończy się niepowodzeniem, jeśli nie ma zasad zabezpieczeń na poziomie wiersza zdefiniowanych w samym zmaterializowanym widoku. Celem niepowodzenia jest powiadamianie użytkownika o potencjalnym wycieku danych, ponieważ zmaterializowany widok może uwidocznić informacje. Aby wyeliminować ten błąd, wykonaj jedną z następujących czynności:
    • Zdefiniuj zasady zabezpieczeń na poziomie wiersza w zmaterializowanym widoku.
    • Wybierz, aby zignorować błąd, dodając allowMaterializedViewsWithoutRowLevelSecurity właściwość do polecenia alter policy. Na przykład:
    .alter table SourceTable policy row_level_security enable with (allowMaterializedViewsWithoutRowLevelSecurity=true) "RLS_function"

Aby uzyskać polecenia służące do konfigurowania zasad zabezpieczeń na poziomie wiersza w zmaterializowanym widoku, zobacz row_level_security polecenia zasad.