Udostępnij za pośrednictwem

Planowanie wdrożenia funkcji OLTP In-Memory w programie SQL Server

  • Artykuł

Dotyczy:SQL ServerAzure SQL DatabaseAzure SQL Managed Instance

W tym artykule opisano, w jaki sposób przyjęcie funkcji w pamięci w programie SQL Server wpływa na inne aspekty Twojego systemu biznesowego.

Notatka

A. Wdrażanie funkcji OLTP In-Memory

W poniższych podsekcjach omówiono czynniki, które należy wziąć pod uwagę podczas planowania wdrażania i wdrażania funkcji In-Memory.

Wymagania wstępne A.1

Jedno wymaganie wstępne dotyczące korzystania z funkcji In-Memory może obejmować wydanie lub warstwę usługi produktu SQL. Aby uzyskać informacje na temat tych i innych wymagań wstępnych, zapoznaj się z:

A.2 Prognozowanie ilości aktywnej pamięci

Czy system ma wystarczającą ilość aktywnej pamięci do obsługi nowej tabeli zoptymalizowanej pod kątem pamięci?

Microsoft SQL Server

Tabela zoptymalizowana pod kątem pamięci, która zawiera 200 GB danych, wymaga więcej niż 200 GB aktywnej pamięci dedykowanej do obsługi. Przed zaimplementowaniem tabeli zoptymalizowanej pod kątem pamięci zawierającej dużą ilość danych należy przewidzieć ilość dodatkowej aktywnej pamięci, którą może być konieczne dodanie do komputera serwera. Aby uzyskać wskazówki dotyczące szacowania, zobacz:

Podobne wskazówki są dostępne dla usługi Azure SQL Managed Instance:

Azure SQL Database

W przypadku bazy danych hostowanej w usłudze w chmurze Azure SQL Database wybrana warstwa usługi wpływa na ilość aktywnej pamięci, z której może korzystać baza danych. Należy zaplanować monitorowanie użycia pamięci bazy danych przy użyciu alertu. Aby uzyskać szczegółowe informacje, zobacz:

Zmienne tabeli zoptymalizowane pod kątem pamięci

Zmienna tabeli zadeklarowana jako zoptymalizowana pod kątem pamięci jest czasami preferowana dla tradycyjnej #TempTable, która znajduje się w bazie danych tempdb. Zmienne tabeli mogą zapewnić wzrost wydajności bez używania znacznej ilości aktywnej pamięci.

Tabela A.3 musi być offline, aby zostać przekonwertowaną na zoptymalizowaną pod kątem pamięci.

Niektóre funkcje ALTER TABLE są dostępne dla tabel zoptymalizowanych pod kątem pamięci. Nie można jednak wydać instrukcji ALTER TABLE w celu przekonwertowania tabeli opartej na dysku na tabelę zoptymalizowaną pod kątem pamięci. Zamiast tego należy użyć bardziej ręcznego zestawu kroków. Poniżej przedstawiono różne sposoby konwertowania tabeli opartej na dyskach w celu zoptymalizowania pod kątem pamięci.

Ręczne wykonywanie skryptów

Jednym ze sposobów konwertowania tabeli opartej na dysku na tabelę zoptymalizowaną pod kątem pamięci jest samodzielne kodowanie niezbędnych Transact-SQL kroków.

  1. Wstrzymaj działanie aplikacji.

  2. Utwórz pełną kopię zapasową.

  3. Zmień nazwę tabeli opartej na dysku.

  4. Wydaj instrukcję CREATE TABLE, aby utworzyć nową tabelę zoptymalizowaną pod kątem pamięci.

  5. WSTAW DO tabeli zoptymalizowanej pod kątem pamięci z wykorzystaniem podzapytania SELECT z tabeli dyskowej.

  6. UPUŚĆ tabelę opartą na dysku.

  7. Wykonaj kolejną pełną kopię zapasową.

  8. Wznów działanie aplikacji.

Doradca optymalizacji pamięci

Narzędzie do optymalizacji pamięci Advisor może wygenerować skrypt, aby ułatwić zaimplementowanie konwersji tabeli przechowywanej na dysku na tabelę zoptymalizowaną pod kątem pamięci. Narzędzie jest instalowane w ramach narzędzi SQL Server Data Tools (SSDT).

Plik dacpac

Bazę danych można zaktualizować w miejscu przy użyciu pliku dacpac zarządzanego przez program SSDT. W programie SSDT można określić zmiany schematu zakodowanego w pliku dacpac.

Pracujesz z plikami dacpac w kontekście projektu programu Visual Studio typu Database.

A.4 Wskazówki dotyczące tego, czy funkcje OLTP In-Memory są odpowiednie dla Twojej aplikacji

Aby uzyskać wskazówki dotyczące tego, czy In-Memory funkcje OLTP mogą poprawić wydajność określonej aplikacji, zobacz:

B. Nieobsługiwane funkcje

Funkcje, które nie są obsługiwane w niektórych scenariuszach In-Memory OLTP, są opisane pod adresem:

W poniższych podsekcjach przedstawiono niektóre z najważniejszych nieobsługiwanych funkcji.

B.1 MIGAWKA bazy danych

Po pierwszym utworzeniu dowolnej tabeli lub modułu zoptymalizowanego pod kątem pamięci w danej bazie danych nie można nigdy migawki bazy danych. Konkretną przyczyną jest to, że:

  • Pierwszy element zoptymalizowany pod kątem pamięci uniemożliwia usunięcie ostatniego pliku z grupy FILEGROUP zoptymalizowanej pod kątem pamięci; i
  • Żadna baza danych, która ma plik w zoptymalizowanej pod kątem pamięci FILEGROUP, nie może obsługiwać migawki.

Zwykle migawka może być przydatna do szybkiego testowania iteracji.

Zapytania między bazami danych B.2

Tabele zoptymalizowane pod kątem pamięci nie obsługują transakcji między bazami danych. Nie można uzyskać dostępu do innej bazy danych z tej samej transakcji lub tego samego zapytania, które uzyskuje również dostęp do tabeli zoptymalizowanej pod kątem pamięci.

Zmienne tabeli nie są transakcyjne. W związku z tym zmienne tabeli zoptymalizowane pod kątem pamięci mogą być używane w zapytaniach obejmujących wiele baz danych.

B.3 wskazówka dotycząca tabeli READPAST

Żadne zapytanie nie może zastosować wskazówki tabeli READPAST do dowolnej tabeli zoptymalizowanej pod kątem pamięci.

Wskazówka READPAST jest przydatna w scenariuszach, w których kilka sesji uzyskuje dostęp do i modyfikuje ten sam mały zestaw wierszy, na przykład w przetwarzaniu kolejki.

B.4 RowVersion, Sekwencja

  • Nie można otagować kolumny dla RowVersion w tabeli zoptymalizowanej pod kątem pamięci.

  • Nie można używać SEQUENCE z ograniczeniem w tabeli zoptymalizowanej pod kątem pamięci. Na przykład nie można utworzyć ograniczenia DOMYŚLNEgo z klauzulą NEXT VALUE FOR. Sekwencje można używać z instrukcjami INSERT i UPDATE.

C. Konserwacja administracyjna

W tej sekcji opisano różnice w administrowaniu bazą danych, w których są używane tabele zoptymalizowane pod kątem pamięci.

C.1 Resetowanie inicjatora tożsamości, przyrost > 1

DBCC CHECKIDENT, aby ponownie ustawić wartość początkową kolumny IDENTITY, nie można użyć w tabeli zoptymalizowanej dla pamięci.

Wartość przyrostowa jest ograniczona do dokładnie 1 dla kolumny IDENTITY w tabeli zoptymalizowanej pod kątem pamięci.

C.2 DBCC CHECKDB nie może zweryfikować tabel zoptymalizowanych pod kątem pamięci

Polecenie DBCC CHECKDB nie wykonuje niczego, gdy jego celem jest tabela zoptymalizowana pod kątem pamięci. Poniższe kroki są obejściem:

  1. utwórz kopię zapasową dziennika transakcji.

  2. Utwórz kopię zapasową plików w grupie FILEGROUP zoptymalizowanej pod kątem pamięci na urządzeniu o wartości null. Proces tworzenia kopii zapasowej wywołuje walidację sumy kontrolnej.

    Jeśli zostanie wykryta korupcja, przejdź do następnych kroków.

  3. Skopiuj dane z tabel zoptymalizowanych pod kątem pamięci do tabel opartych na dyskach na potrzeby magazynu tymczasowego.

  4. Przywróć pliki z grupy FILEGROUP zoptymalizowanej pod kątem pamięci.

  5. WSTAW DO tabel zoptymalizowanych pod kątem pamięci danych tymczasowo przechowywanych w tabelach opartych na dyskach.

  6. UPUŚĆ tabele oparte na dyskach, które tymczasowo przechowywały dane.

D. Wydajność

W tej sekcji opisano sytuacje, w których doskonała wydajność tabel zoptymalizowanych pod kątem pamięci może być przechowywana poniżej pełnego potencjału.

Zagadnienia dotyczące indeksu D.1

Wszystkie indeksy w tabeli zoptymalizowanej pod kątem pamięci są tworzone i zarządzane przez instrukcje związane z tabelą CREATE TABLE i ALTER TABLE. Nie można zastosować instrukcji CREATE INDEX w przypadku tabeli zoptymalizowanej pod kątem pamięci.

Tradycyjny indeks nieklastrowany drzewa B jest często rozsądnym i prostym wyborem podczas pierwszej implementacji tabeli zoptymalizowanej pod kątem pamięci. Później, gdy zobaczysz, jak działa aplikacja, możesz rozważyć zamianę innego typu indeksu.

Notatka

W dokumentacji jest zwykle używany termin B-tree w odniesieniu do indeksów. W indeksach rowstore silnik bazy danych implementuje drzewo B+. Nie dotyczy to indeksów magazynu kolumn ani indeksów w tabelach zoptymalizowanych pod kątem pamięci. Aby uzyskać więcej informacji, zobacz przewodnik dotyczący architektury indeksów i projektowania w SQL Server i Azure SQL.

Dwa specjalne typy indeksów wymagają omówienia w kontekście tabeli zoptymalizowanej pod kątem pamięci: indeksy skrótów i indeksy kolumnowe.

Aby zapoznać się z omówieniem indeksów w tabelach zoptymalizowanych pod kątem pamięci, zobacz:

Indeksy skrótów

Indeksy haszy mogą być najszybszym formatem dostępu do jednego konkretnego wiersza za pomocą jego dokładnej wartości klucza podstawowego, używając operatora '='.

  • Operatory niedokładne, takie jak "!=", ">" lub "MIĘDZY", wpływałyby negatywnie na wydajność, gdyby były używane z indeksem skrótu.

  • Indeks skrótu może nie być najlepszym wyborem, jeśli poziom duplikowania wartości kluczowej staje się zbyt wysoki.

  • Unikaj niedoceniania, ile zasobników może potrzebować twój indeks skrótu, aby uniknąć długich łańcuchów w poszczególnych zasobnikach. Aby uzyskać szczegółowe informacje, zobacz:

Nieklastrowane indeksy magazynu kolumn

Tabele zoptymalizowane pod kątem pamięci zapewniają wysoką przepływność typowych danych transakcyjnych biznesowych, w tym, co nazywamy przetwarzaniem transakcji online lub OLTP. Indeksy columnstore zapewniają wysoką wydajność agregacji i podobne przetwarzanie, które nazywamy Analytics. W przeszłości najlepszym podejściem dostępnym do zaspokojenia potrzeb zarówno OLTP, jak i Analytics, było posiadanie oddzielnych tabel z dużym przepływem danych oraz z pewnym stopniem duplikacji danych. Obecnie dostępne jest prostsze rozwiązanie hybrydowe : indeks magazynu kolumn w tabeli zoptymalizowanej pod kątem pamięci.

  • Indeks columnstore można utworzyć w tabeli przechowywanej na dysku, nawet jako indeks klastrowany. Jednak w tabeli zoptymalizowanej pod kątem pamięci nie można tworzyć klastra dla indeksu columnstore.

  • Kolumny LOB lub kolumny przechowywane poza wierszem w tabeli zoptymalizowanej pod kątem pamięci uniemożliwiają utworzenie indeksu kolumnowego w tabeli.

  • Nie można wykonać instrukcji ALTER TABLE na tabeli zoptymalizowanej pod kątem pamięci, gdy na tabeli istnieje indeks columnstore.

    • Od sierpnia 2016 r. firma Microsoft planuje w najbliższym czasie poprawić wydajność procesu ponownego tworzenia indeksu magazynu kolumn.

D.2 LOB i kolumny poza wierszem

Duże obiekty (LOB) to kolumny takich typów jak varchar(max). Posiadanie kilku kolumn LOB w tabeli zoptymalizowanej pod kątem pamięci prawdopodobnie nie ma na tyle dużego wpływu na wydajność, aby to miało znaczenie. Należy jednak unikać posiadania większej liczby kolumn LOB, niż wymaga tego dane. Te same porady dotyczą kolumn między wierszami. Nie należy definiować kolumny jako nvarchar(3072), jeśli wartość varchar(512) wystarczy.

Więcej informacji o kolumnach LOB i nieskladowanych wierszach można znaleźć pod adresem:

E. Ograniczenia natywnych procedur

Określone elementy Transact-SQL nie są obsługiwane w natywnie skompilowanych modułach języka T-SQL, w tym w procedurach składowanych. Aby uzyskać szczegółowe informacje o obsługiwanych funkcjach, zobacz:

Aby zapoznać się z zagadnieniami dotyczącymi migrowania modułu Transact-SQL, który używa nieobsługiwanych funkcji do natywnego kompilowania, zobacz:

Oprócz ograniczeń dotyczących niektórych elementów języka Transact-SQL istnieją również ograniczenia dotyczące operatorów zapytań obsługiwanych w natywnie skompilowanych modułach języka T-SQL. Ze względu na te ograniczenia, natywnie skompilowane procedury składowane nie są odpowiednie dla zapytań analitycznych, które przetwarzają duże zestawy danych.

Brak przetwarzania równoległego w natywnym procesie

Przetwarzanie równoległe nie może być częścią żadnego planu zapytania dla natywnej procedury. Natywne procesy są zawsze jednowątkowe.

Typy połączeń

Oba łączenia haszujące i łączenia scalające nie mogą być częścią żadnego planu zapytania dla natywnej procedury. Sprzężenia zagnieżdżonych pętli są używane.

Brak agregacji haszy

Jeśli plan zapytania dla natywnej procedury wymaga fazy agregacji, dostępna jest tylko agregacja strumieniowa. Agregacja haszów nie jest obsługiwana w planie zapytania dla natywnej procedury.

  • Agregacja haszująca jest lepsza, gdy dane z dużej liczby wierszy należy agregować.

F. Projekt aplikacji: transakcje i logika ponawiania prób

Transakcja obejmująca tabelę zoptymalizowaną pod kątem pamięci może stać się zależna od innej transakcji, która obejmuje tę samą tabelę. Jeśli liczba transakcji zależnych osiągnie dozwoloną wartość maksymalną, wszystkie zależne transakcje kończą się niepowodzeniem.

W programie SQL Server 2016:

  • Dozwolona wartość maksymalna to osiem zależnych transakcji. Osiem jest również limitem transakcji, od których może zależeć każda dana transakcja.
  • Numer błędu to 41839. (W programie SQL Server 2014 numer błędu to 41301).

Możesz uczynić swoje skrypty Transact-SQL bardziej odpornymi na możliwe błędy transakcji, dodając do nich logikę ponawiania prób . Logika ponawiania prób jest bardziej skuteczna, gdy wywołania UPDATE i DELETE występują często, lub jeśli tabela zoptymalizowana pod kątem pamięci jest referencją w kluczu obcym w innej tabeli. Aby uzyskać szczegółowe informacje, zobacz:

Powiązana zawartość