Ostatnio zderzyłem się z wydajnością jednej z procedur składowanej (ang. stored procedure), a mianowicie - łączenie tabeli z inną tabelą po kolumnie tupy NVARCHAR(MAX) daje bardzo słabą wydajność prz >1k rekordów w tabeli. Teraz każdy może powiedzieć - no panie, wiadomo że trzeba założyć indeksy :-) I macie racje, tylko że SQL Server nie pozwala tworzyć indeks na gdy rozmiar wszystkich kolumn w indeksie przekracza 900 bajtów (link). A więc zaczęłem myśleć i szukać rozwiązania.

W trakcie mojej niedawnej prezentacji poświęconej technologii in-memory OLTP w systemie SQL Server 2014 padło pytanie (w pełni zasadne), czy w związku z wprowadzeniem na potrzeby definiowania tabel in-memory możliwości definiowania indeksów inline w składni polecenia CREATE TABLE podobne definiowanie indeksów będzie możliwe dla tradycyjnych tabel. Okazuje się, że tak. W dokumentacji SQL Server 2014 w części poświęconej nowościom w silniku bazodanowym została wymieniona specyfikacja indeks...

Myślałem trochę nad tematami na następne wpisy i sądzę, że jest sporo tematów, nad którymi wypada się pochylić, zarówno tematów dla DBA/DEV, jak i tematów z zakresu Business Intelligence. Pierwszy temat wpadł mi do głowy przy okazji przygotowywania prezentacji na 61. spotkanie warszawskiego oddziału PLSSUG (Polish SQL Server User Group). Wspólnie z Małgosią Borzęcką zaprezentowałem wprowadzenie do indeksów columnstore. W zasadzie chyba używając słowa “wprowadzenie” dokonałem nadużycia :-) Sesja miała co...

Może wydarzyć się sytuacja, że zajdzie konieczność utworzenia unikalnego klucza na kolumnie typu tekstowego (CHAR lub VARCHAR). W tym momencie warto nadmienić, iż każdy znak zajmie wtedy 1 bajt. Jeśli zaś będzie to typ danych unicode (NCHAR lub NVARCHAR), to znak zapisany będzie na 2 bajtach pamięci. Dlaczego o tym wspominam? Ponieważ jeśli wielkość indeksu przekroczy magiczną granicę 900 bajtów pojawia się Error 1946...