Poprawianie wydajności kwerend Ad-Hoc - sql, sql-server, tsql, amazon-ec2, sql-server-2012

Detale: SQL Server 2012. Architektura DB dla wielu najemców.

Mam problem z generowaniem przez użytkownika zapytań raportujących ad-hoc blokujących moje okno SQL.

Typowy raport może zawierać 7 tabel (odod 10 tys. rzędów do ponad 500 tys wiersze), 5 klauzul WHERE i 2 filtry sortujące. Te zapytania, jak możesz wyobraź sobie, są dość drogie i mogą zająć minuty. Problemem jest zapytania te maksymalnie wykorzystują procesor SQL i mogą zająć ponad 20 GB tempdb przestrzeń. Powoduje to przekroczenie limitu czasu każdej innej aplikacji korzystającej z bazy danych.

Ponieważ są to raporty generowane przez użytkowników, nie jestem w stanie dostroić zapytań pod kątem wydajności. Przy ponad 2000 klientach i ich wzroście, udzielanie każdemu klientowi własnego zestawu widoków lub schematów nie wchodzi w rachubę.

Moje pytanie brzmi: jak dostroić moją bazę danychzapytania ad-hoc lub w jakiś sposób ograniczają zapytanie, aby nie zajmowało wszystkich zasobów serwera? W tej chwili, jeśli ktoś uruchomi duży raport, cały serwer zawiesza się, dopóki nie zresetuję usługi SQL. Oczywiście nie jest to możliwe.

Czy istnieje najlepsza praktyka dotycząca drogich zapytań dla wielu dzierżawców bazy danych?

EDYTOWAĆ:

Mam zapytanie, które może odtworzyć problem,jednak jeśli uruchomię go na moim lokalnym serwerze programistycznym, tempDB wzrośnie tak samo, ale proces nie zużywa procesora, tak jak ma to miejsce w mojej instancji AWS. (3% procesora na poziomie lokalnym i 58% na poziomie EC2 m3.large).

Lokalny procesor - Intel Xeon E3-1230 V2

Procesor EC2 - Intel Xeon E5-2670 V2

Z tego, co widzę, wszystkie ustawienia serwera są prawie identyczne.

Odpowiedzi:

Mieliśmy podobny problem w mojej firmie. Zastosowaliśmy wielopunktowe rozwiązanie do kontrolowania niekontrolowanych zapytań ad hoc. To może / może nie być dla ciebie przydatne. W skrócie nasz projekt był:

• Użyliśmy regulatora zasobów do zdefiniowania basenów i grup roboczych. Wszystko sklasyfikowano połączenia aplikacji / interfejs użytkownika / zapytania niższego szczebla, powiedzmy, grupa 1 / pula 1.
• Wszystkie połączenia użytkowników zostały zaklasyfikowane do grupy 2 / puli 2
• Tylko grupa 2 / pula 2 była ograniczona tylko do dostępu20% zasobów procesora. Pamiętaj, że zostanie to wywołane i zastosowane tylko w przypadku nowych połączeń po obciążeniu serwera. Oznacza to, że gdy serwer jest przeciążony, wszystkie nowe połączenia kwalifikujące się do puli 2 zostaną ograniczone.
• Musieliśmy także zabić wszelkie niekontrolowane zapytania, jeśliserwer jest w stresie. Podnieśliśmy więc zdarzenie „okna” na wypadek, gdyby zapytania z puli 2 działały przez ponad 10 minut. Usługa systemu Windows uzyska informacje o niekontrolowanych zapytaniach i wstawi dane do tabeli sprzątania.
• Agent SQL uruchamiałby się co 10 minut i szukał zapytań wstawionych do tabeli sprzątania i zabijałby te zapytania.

To kompleksowe rozwiązanie, które można dostosować i wdrożyć w razie potrzeby.