2012-01-30 14 views
5

Mam tabeli CurrentStatus w mojej bazy danych (bazy danych subskrypcji w replikacji scalania) Kolumny są StatusID {Primary Key + Clustered Index}, StatusName, StatusDate, UserID,CreatedDate, ModifiedDate, ModifiedBy, AllowDelete,AllowUpdateProste zapytanie zmiana trwa zbyt długo

currentStatus tabeli jako 26000 wierszy

aktualizacje i usuwa w tej tabeli są Nagle za dużo czasu mówi się od 1 minuty 30 sekund do nawet 5 minut.

Wykonanie poniższej zapytania trwa ponad minutę.

update StatusMaster set StatusName='OK' where StatusID = 22 

Były wcześniej 5 indeksów na stole (nawet wtedy zapytań wykorzystywane do wykonywania szybko.) Teraz jako aktualizacji/usuwania zapytań nie realizują, mam usunięte wszystkie indeksy i przechowywane tylko dwa indeksy 1) Indeks klastrowany na StatusID 2) Indeks replikacji w kolumnie rowguid, który jest unikalnym nieklastrowanym indeksem utworzonym automatycznie przez replikację.

Po wykonaniu kopii zapasowej i odtworzeniu bazy danych, zapytania w tej samej tabeli działają poprawnie.

Jeszcze jedno, że mam złożone zapytanie uruchamiane co 2 minuty z około 20 komputerów na serwerze.

Co powoduje, że te zapytania pochłaniają tak dużo czasu na wykonanie?

Click here for Execution plan

+0

to replikacja uruchomiona po wykonaniu tych testów? Jeśli DB jest subskrybentem, to faktycznie nie powinieneś usuwać \ aktualizowania jego danych, prawda? – Diego

+0

Nie publikuj w WIELKICH LATACH. Jest niegrzeczny i wydaje się, że "krzyczysz". –

+1

@Diego replikacja tak działa + replikacja scalania, więc wstawianie aktualizacji może działać na dowolnym subskrybencie i wydawcy – Thakur

Odpowiedz

6

I zaleca, aby uaktualnić swoje statystyki poprzez komendę UPDATE STATISTICS, np:

UPDATE STATISTICS StatusMaster 
+0

jego pomógł zmniejszyć czas wykonania, ale nadal biorąc 20 nieparzystych sekund – Thakur

+0

czasami zajmuje 1 sekundę, a czasem ponad 15 sekund, zużycie pamięci na serwerze to 2,5 GB z 4 GB i wykorzystanie procesora wynosi 45% – Thakur

+0

Możliwe jest, że kolumna 'StatusID' ma niską liczność tak, że wykonuje skanowanie tabeli. Co mówi twój plan wykonania? – RedFilter

2

Po wielu wkładek, usuwa aktualizacje, itp, to tabela może uzyskać rozdrobniony i swój indeksy mogą nie być zoptymalizowane. Sugerowałbym ponowne indeksowanie i aktualizowanie statystyk.

Po zrobieniu kopii zapasowej i przywróceniu jej, wierzę, że dokonujesz tego samego, co zrobiłby ponownie indeks i aktualizacja statystyk.

Powinieneś zaplanować taką konserwację regularnie, aby utrzymać wydajność.

+0

odbudowałem indeksy i zaktualizowałem statystyki, ale nadal stoję przed problemem – Thakur

0

Ostatnim razem, gdy kilka prostych zapytań zajęło nienormalny czas [w naszej małej firmie], było to spowodowane uszkodzeniem macierzy RAID na [na szczęście nieprodukcyjnym] serwerze SQL.

+0

jak mogę znaleźć, czy moja macierz RAID jest uszkodzona? – Thakur

+0

Zapytaj osobę, która administruje tym komputerem, w którym znajduje się serwer SQL. Należy sprawdzić dzienniki zdarzeń systemu Windows i, jeśli są obecne, dzienniki stanu kontrolera RAID. Nie mówię, że to jest twój przypadek - nie mam doświadczenia z replikacją i nie mogę powiedzieć, jaki wpływ może to spowodować; Po prostu zasugerowałem, że czasami dziwne opóźnienia są spowodowane problemami sprzętowymi. – Arvo

+0

Ponieważ ta tabela jest w replikacji i dostaję błąd na 4 do 5 serwerów nie sądzę, że będzie to problem z macierzą RAID – Thakur

Powiązane problemy