
W dniu 9 lutego 2019 odbyła się po raz trzeci w Polsce, a po raz drugi w Krakowie konferencja SQL Saturday #824, na której poprowadziłem sesję „Cut the tables into partitions v.2”






W dniu 9 lutego 2019 odbyła się po raz trzeci w Polsce, a po raz drugi w Krakowie konferencja SQL Saturday #824, na której poprowadziłem sesję „Cut the tables into partitions v.2”
Poniżej przedstawiam kilka dobrych ogólnie znanych praktyk kierowanych do administratorów baz danych MS SQL Server związanych z utrzymaniem środowiska.
Podczas instalacji SQL Server 2019 dwa serwisy:
nie uruchamiały się. Był generowany błąd „The request failed or the service did not respond in a timely fashion„
Przyczyn tego błędu może być kilka:
1. Wygaśnięcie hasła dla konta, na którym uruchomiona była usługa
2. Zmiana hasła dla konta, na którym była uruchomiona usługa bez aktualizacji poświadczeń dla usługi
3. Nieprawidłowa konfiguracja protokołów sieciowych
W tym wypadku była to nieprawidłowa konfiguracja protokołów sieciowych. Należy uruchomić SQL Server Configuration Manager i w SQL Server Network Configuration\Client Protocols oraz w SQL Native Client 11.0 Configuration \Client Protocols włączyć TCP/IP oraz Named Pipes.
Po tej czynności wystarczy zrestartować usługi SQL Server a następnie ponownie uruchomić usługi Polybase
SQL Server 2016 wprowadza modyfikację do instrukcji TRUNCATE TABLE, która pozwala czyścić określoną partycję lub zestaw partycji z tabeli, jednocześnie uzyskując zalety instrukcji TRUNCATE TABLE bez usuwania wszystkich danych z tabeli. Ten nowy mechanizm filtru w instrukcji TRUNCATE TABLE jest uzyskiwany za pomocą opcji WITH PARTITIONS () określającej partycję lub zestawy partycji.
1 2 3 4 5 |
TRUNCATE TABLE [ { database_name .[ schema_name ] . | schema_name . } ] table_name [ WITH ( PARTITIONS ( { <partition_number_expression> | <range> } [ , ...n ] ) ) ] [ ; ] <range>::= <partition_number_expression> TO partition_number_expression> |
Przykład użycia:
Bardzo często zdarza się, że trzeba dokonać zmian na wielu milionach rekordów. Wykonując update czy delete na takiej ilości rekordów w ramach jednej transakcji doprowadzamy do sytuacji rozrostu loga transakcyjnego.
Oczywiście jeżeli byśmy takie operacje wykonywali małymi porcjami to powstało by dużo transakcji i po zakończeniu każdej z nich silnik sql serwera wstawiał by ponownie dane do loga transakcyjnego wykorzystując już zwolnione miejsca (Recovery model = SIMPLE)
Poniżej przedstawiam przykładowy kod:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 |
use Foo go declare @i int =1 declare @x int=0 set rowcount 50000; -- będzie wykonywał update tylko na 50000 rekordów while @i>0 begin UPDATE Foo.dbo.Tabela SET kolumna = wartosc WHERE {predykat} set @i=@@ROWCOUNT set @x=@x+@i end set rowcount 0 |
W SQL Server można wykonać odbudowę indeksu dla wybranej partycji. Nie trzeba już przebudowywać całego indeksu na całej wybranej tabeli partycjonowanej.
Oczywiście we wcześniejszych wersjach mając SQL Server 2012 w codziennym procesie zasilania korzystając z danych ETL, stosowano dość powszechną praktykę:
Praca w ten sposób jest zwykle optymalna, ponieważ SQL Server nie musi aktualizować NCI podczas importowania danych. Wyobraź sobie jednak, że mamy siedem lat danych. Oznacza to 7 * 12 = 94 partycji, z których tylko jedna partycja jest aktywna. Dla nas odbudowanie całego indeksu będzie prawie 99% zbędna
Od wersji SQL Server 2008 można już przebudować indeks na wybranej partycji.