Tuning SQL Server dla serwerów WWW Prowadzący: Cezary Ołtuszyk
Zapraszamy do współpracy!
Plan szkolenia I. Wprowadzenie do tematu II. Nawiązywanie połączenia z SQL Server III. Parametryzacja i przygotowanie zapytań IV. Jedna czy wiele wartości? V. Przechowywanie stanu sesji, a IN MEMORY OLTP VI. Podsumowanie
Wprowadzenie do tematu
Wprowadzenie do tematu
Nawiązywanie połączenia z SQL Server Konta aplikacyjne, czy osobne dla każdego użytkownika? Uwierzytelnianie WINDOWS, czy SQL SERVER? Jeżeli uwierzytelnianie WINDOWS to NTLM czy KERBEROS?
Nawiązywanie połączenia z SQL Server Pula połączeń w SQL SERVER: Połączenia do serwera są drogie (94KB + 3 x NETWORK PACKET SIZE) Powinno być mniej połączeń niż użytkowników ADO Connection String ma odpowiednie ustawienia (domyślny przedział puli wynosi 1-100) Jedna pula połączeń jest tworzona dla: Procesu Aplikacji Connection String-u (ważna baza!!!) Dla każdego użytkownika przy uwierzytelnianiu WINDOWS
Parametryzacja i przygotowanie zapytań Droga naszego zapytania wygląda następująco:
Parametryzacja i przygotowanie zapytań Która z opcji poniżej jest bardziej wydajna? SELECT sod.salesorderid, SalesOrderDetailID, ProductID, LineTotal FROM Sales.SalesOrderDetail AS sod WHERE sod.salesorderid = 70000 VS SELECT sod.salesorderid, SalesOrderDetailID, ProductID, LineTotal FROM Sales.SalesOrderDetail AS sod WHERE sod.salesorderid = @id
Jedna czy wiele wartości?
Przechowywanie stanu sesji: podstawy IN MEMORY OLTP
Przechowywanie stanu sesji: podstawy IN MEMORY OLTP Durable optimized tables: Tabele, które po uruchomieniu bazy SQL Server ładuje do RAM, ale ich dane są zapisane na dysku twardym serwera Non durable optimized tables: Tabele, które istnieję jedynie w pamięci RAM, po restarcie serwera tracimy zawarte w nich informacje Natively Compiled Stored Procedures and Functions: Procedury składowane i funkcje skalarne użytkownika, które są przekompilowane do kodu natywnego, dzięki czemu SQL Server nie musi ich interpretować podczas wykonania. No Locks + Row Versioning: Rekordy w tabelach In memory mają wbudowana kontrole wersji i nie używają tradycyjnych mechanizmów blokujących
Przechowywanie stanu sesji: podstawy IN MEMORY OLTP Przykładowy kod tworzący bazę wspierającą tabele In Memory : CREATE DATABASE InMemDB ON PRIMARY ( NAME = [InMemDB_data], FILENAME = 'Q:\data\InMemDB_data.mdf', SIZE = 500MB ), FILEGROUP [SampleDB_mod_fg] CONTAINS MEMORY_OPTIMIZED_DATA ( NAME = [InMemDB_mod_dir], FILENAME = 'R:\data\InMemDB_mod_dir ' ) LOG ON ( NAME = [InMemDB_log], FILENAME = 'L:\log\InMemDB_log.ldf', SIZE = 500MB ) ;
Przechowywanie stanu sesji: podstawy IN MEMORY OLTP Przykładowy kod tworzący tabelę: CREATE TABLE [dbo].[tblinmemtable] ( [message_id] [int] NOT NULL, [language_id] [smallint] NOT NULL, [severity] [tinyint] NULL, [is_event_logged] [bit] NOT NULL, [text] [nvarchar](2048) NOT NULL, [testid] int NOT NULL INDEX IX_tblLookupMem_testID, CONSTRAINT PK_tblLookupHash PRIMARY KEY NONCLUSTERED (message_id, language_id) ) WITH (MEMORY_OPTIMIZED = ON)
Przechowywanie stanu sesji: podstawy IN MEMORY OLTP
Przechowywanie stanu sesji: podstawy IN MEMORY OLTP Podsumowanie: 1. Jeżeli uwierzytelnianie WINDOWS, to tylko KERBEROS 2. Umiejętnie dobierajmy ilość połączeń w puli 3. Domyślnie używajmy parametryzacji zapytań 4. Oceńmy jak wygląda złoty środek jeśli chodzi o pobieranie danych w naszej aplikacji 5. IN MEMORY OLTP = zero zakleszczeń