Microsoft SQL Server 2008

SQL Pytania i Odpowiedzi: Indeksy nieklastrowe i zachowywanie uprawnień Udostępnij na: Facebook

Saleem Hakani oraz Dan Carollo

Opublikowano: 29 sierpnia 2008 | Zaktualizowano: 29 sierpnia 2008

Zawartość strony
Indeksy nieklastrowe i ich zastosowania  Indeksy nieklastrowe i ich zastosowania
Zachowywanie danych o uprawnieniach  Zachowywanie danych o uprawnieniach

 

 

Indeksy nieklastrowe i ich zastosowania

  Co to są indeksy nieklastrowe i jaki są zalety oraz wady ich stosowania?
Odp.

Indeks nieklastrowy przypomina rodzaj indeksu, który znajdujemy zazwyczaj na końcu książki. Wszystkie informacje znajdujące się w książce są reprezentowane w indeksie przez temat i wskaźniki w postaci numerów stron, które wskazują, gdzie można odnaleźć informacje (czasem w kilku miejscach książki). Co więcej, dane w indeksie książki nie są wymienione w takiej samej kolejności, w jakiej pojawiają się one w tekście książki. Podobnie jest w przypadku indeksów nieklastrowych. Gdy mamy do czynienia z klastrowym indeksem w tabeli, możemy określić porządek elementów. W przeciwnym wypadku nie możemy mieć pewności, jaka będzie ich kolejność.

Ponadto, indeksy nieklastrowe posiadają dwa ograniczenia: indeks może objąć jedynie 16 kolumn i maksymalny rozmiar klucza indeksy nie może przekraczać 900 bajtów. Co to oznacza? Przyjrzyjmy się, co się stanie, gdy chcemy zaindeksować następujące kolumny w tabeli Movie z przykładowej bazy danych MovieList: MovieTitle NVarchar(50), DirectorName NVarchar(50), ShortStory NVarchar(400).

Załóżmy, że wywołamy następującą instrukcję w celu stworzenia indeksu w tabeli:

 Use MovieList; CREATE INDEX Movie_IDX ON Movie(MovieTitle, DirectorName, ShortStory); 

Spowoduje ona pojawienie się następującego komunikatu o błędzie: "Warning! The maximum key length is 900 bytes. The index 'Movie_IDX' has maximum length of 1000 bytes". W przypadku pewnych kombinacji dużych wartości, operacja wstawiania/aktualizacji nie powiedzie się. Powyższy komunikat zostanie wyświetlony, ponieważ typ danych "nvarchar" wykorzystuje po 2 bajty dla każdego znaku. A zatem indeks zawierający zaprezentowane trzy kolumny przekroczyłby limit rozmiaru wynoszący 900 bajtów.

Dzięki opublikowaniu wersji SQL Server® 2005, pojawiła się możliwość ominięcia tego problemu poprzez dodanie kolumn do klauzuli INCLUDE. Funkcja ta jest bardzo pomocna, gdy chcemy pokonać ograniczenia rozmiaru oraz liczby kolumn. Możemy to osiągnąć, wykonując następującą instrukcję:

 CREATE INDEX Movie_IDX ON Movie(MovieTitle, DirectorName) INCLUDE (ShortStory); 

Należy zauważyć, że gdy podczas tworzenia indeksu wykorzystujemy klauzulę INCLUDE, aparat bazy danych, obliczając liczbę kolumn lub rozmiar klucza indeksu, nie bierze pod uwagę kolumn, które nie należą do klucza.

Aby poznać dodatkowe, pomocne informacje na temat indeksów nieklastrowych, warto zajrzeć do artykułu "Non-clustered Indexes" (msdn2.microsoft.com/aa174537) oraz do artykułu "Using Non-clustered Indexes" (msdn2.microsoft.com/aa933130). Wskazówki na temat optymalizowania indeksów znaleźć można pod adresem sql-server-performance.com/optimizing_indexes.asp.

 

Zachowywanie danych o uprawnieniach

  W jaki sposób można uniknąć utraty uprawnień podczas ponownej inicjalizacji subskrypcji? Wielokrotnie spotkałem się z takim problemem, że gdy migawka była ponownie inicjalizowana, traciła wszystkie przyznane jej uprawnienia.
Odp.

Domyślnie wszystkie obiekty w bazie danych subskrypcji zostają usunięte i stworzone powtórnie, gdy subskrypcja jest ponownie inicjalizowana. Jednak istnieją dwie metody radzenia sobie z tą sytuacją.

Po pierwsze, można powtórnie zastosować wszystkie uprawnienia po ponownej inicjalizacji. Podczas ręcznego konfigurowania uprawnień należy zapisywać w skrypcie wszystkie uprawnienia na poziomie obiekt/instrukcja i przechowywać je w osobnym miejscu, aby można było zastosować je od razu po ponownej inicjalizacji subskrypcji.

Po drugie, można skonfigurować subskrypcję tak, aby nie usuwała ona żadnych obiektów podczas ponownej inicjalizacji. W tym celu należy użyć systemowej procedury składowanej SP_CHANGEARTICLE w celu ustawienia wartości PRE_CREATION_CMD dla parametru @PROPERTY oraz wartości NONE, DELETE lub TRUNCATE dla parametru @Value.

Można również wybrać w oknie dialogowym Article Properties w sekcji obiektu docelowego opcję "Keep existing object unchanged, delete data. If article has a row filter, delete only what matches the filter. Truncate all data in the existing object". Ustawienie to należy przetestować we własnym środowisku testowym. Jeśli potrzebna jest dodatkowa pomoc, warto sprawdzić najnowszą wersję dokumentacji SQL Server Books Online w poszukiwaniu aktualnych informacji.


Więcej informacji

Saleem Hakani pełni funkcje Senior Database Engineer, Senior Problem Engineer oraz Worldwide Microsoft SQL Server Community Lead i posiada 14-letnie doświadczenie w dziedzinie systemów bazodanowych. Prowadzi zewnętrzną witrynę sieci Web SQL Server Community sqlcommunity.com. Można skontaktować się z nim przy użyciu adresu Saleem@sqlcommunity.com.
Dan Carollo pełni funkcje Operations Engineer oraz SQL Server DBA i pracuje w ramach zespołu Windows Anti-Malware Research and Response w firmie Microsoft. Posiada certyfikat MCT w zakresie SQL Server.

 Do początku strony Do początku strony


Microsoft SQL Server 2008