Category: 
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”
#CU
ADO.NET
ASP.NET
C#
Certyfikacje
CRM
DBA
DWH
Egzaminy
Eventy on-Line
Instalacja oprogramowania
MCP
MCTS
Microsoft
MSDN
MS Dynamics
MS SQL Server
One note
PolyBase
Publikacje
RDP
Silverlight
Skrypty
Społeczność
SQL
SQLDay
SQL Saturday
SSIS
SSMS
Systemy
T-SQL
TFS
Virtualizacja
VirtualStudy.pl
Visual Studio
VPN
Web
Windows
Windows Phone
Windows Server
WSS
My Communities
W lutym 2018 r. na spotkaniu warszawskiej grupy Data Comunnity Poland prowadziłem sesję o tematyce partycjonowania „Kroimy tabele na partycje”. Ze względu na duże zainteresowanie postanowiłem powtórzyć tę sesję na SQL Saturday #824 w Krakowie, ale w nieco zmienionej formie. Podczas tej sesji zaprezentowana zostanie jedna z technik optymalizacji baz danych, czyli podział tabel i indeksów bazy danych SQL Server. Pozwala to poprawić wydajność, rozumianą jako szybkość dostępu do danych i ułatwia zarządzanie. Partycjonowanie wiąże się z różnymi mechanizmami, takimi jak przełączanie partycji, okno przesuwne strefy lub eliminacja partycji, które mogą być pomocne w codziennej pracy. Omówimy podstawowe pojęcia, metody podziału, zalety i wady dobrych praktyk. Wspomnę o mitach o podziałach. Wszystko będzie poparte przykładami.
Zapraszam wszystkich na moją sesję „Cut the tables into partitions v.2„, która odbędzie się 9 lutego 2019 r. na konferencji SQL Saturday #824 w Krakowie.
Czytaj dalej
Poniżej przedstawiam kilka dobrych ogólnie znanych praktyk kierowanych do administratorów baz danych MS SQL Server związanych z utrzymaniem środowiska.
- Tworzenie i utrzymywanie standaryzowanego środowiska – jeżeli tylko mamy taką możliwość starajmy się doprowadzić do ujednolicenia konfiguracji używanych serwerów MS SQL Server. Należy również starać się używać tego samego systemu Windows Server OS i wersji i wydań SQL Server. Podobnie należy starać się utrzymywać wszystkie swoje zadania utrzymania baz danych i zadania SQL Agent tak samo (przyjęta konwencja nazewnicza, konta techniczne itp.). Jeśli to jest tylko możliwe ustawiajmy te same parametry serwera czy też baz danych (Collation, Ansi Nulls, Arithmetic abort itp., unifikacja ścieżek dla data, logu i backupu). Utrzymanie standaryzowanego środowiska zmniejszy złożoność operacyjną i zmniejszy ryzyko wystąpienia błędów.
- Twórzmy serwery baz danych jako dedykowane tylko do usług SQL Server – instancje SQL Server powinny zawsze działać na dedykowanym serwerze, nie powinny być na tych serwerach instalowane dodatkowe aplikacje czy usługi nie związane z SQL...
SQL SERVER 2019 – Błąd przy uruchamianiu serwisów Polybase – The request failed or the service did not respond in a timely fashion
31 grudnia 2018
Podczas instalacji SQL Server 2019 dwa serwisy:
- SQL Server PolyBase Engine
- SQL Server PolyBase Data Movement
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:
- TRUNCATE TABLE dbo.powerSQLPartitionTestTable WITH (PARTITIONS (2));
- TRUNCATE TABLE dbo...
Update w pętli dużej ilości danych tak aby nie przepełnić loga
23 października 2018
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 |
