Avatar billede Syska Mester
22. august 2009 - 20:26 Der er 8 kommentarer og
1 løsning

DELETE rows tager MEGA lang tid

Hej,

Jeg importere hver dag data fra forskellige servere ... jeg har så et Unique ID for hver server ( SID ) ... og så har de forskellige elementer deres eget ID, på den måde kan jeg så have det i samme table. Det bliver så brugt som min sammensat Clustered key, da alle opslag er specifikt på en server og på den her måde ligger de fysisk tæt på disken og giver bedre performance, og jeg er fri for at vedlige holde et ekstra Unique ID, som sådan set ikke kan bruges til noget.

Nogen gange skal jeg så have slettet alt data fra et bestemt Server ID ...

Men af en eller anden sær grund går mine delete nu helt galt ...

Før grunde jeg bare
DELETE FROM table WHERE SID = 10; - tog ca. 25 mins, men det virkede ...

Jeg lavede det så om til:
DELETE TOP (@Antal) FROM table WHERE SID 10 10; - halverede tiden. Hvor den så looper  indtil der ikke er flere rows at slette.

Nu er mit problem så at af en eller anden sjov grund ... så tager det 3-4 timer nu ... ARGH, og den kan jeg ikke lige dreje.

Her er et billede af en Execution Plan:
http://peecee.dk/uploads/082009/capper-0.jpeg

Hvor jeg bare kører en DELETE TOP (100) FROM table.

De andre tables der kan ses er child talbes med relation til den her, som er parent.

Data i de child tables er slettet og det går fint nok ... det er alle mine parent tables hvor execution time er helt hen i skoven.

Jeg er godt klar over at databasen skal flytte nogen data pages og nogen udgår når jeg har mit Clustered Key på den måde ... men i sidste ende vinder jeg forhåbelig på det, da som sagt ... data altid bliver taget ud fra SID'et.

Hvis der skal bruges mere info, så sig endelig til ...

// ouT
Avatar billede Slettet bruger
23. august 2009 - 04:35 #1
Jeg går ud fra at SID er spredt fysisk over flere server i et netværk. Har du checket deres individuelle log for problemer ?
Avatar billede Syska Mester
23. august 2009 - 12:47 #2
(SID, ID) er en sammensat clustered primary key ...

Insert af denne er intet problem.

MEn delete går af grunde helt galt ...

// ouT
Avatar billede HenrikSjang Nybegynder
25. august 2009 - 18:16 #3
Måske kan det være noget så simpelt som locking issues du er ude i?

Prøv evt at tjekke waits/locks mens din query kører.

"Det bliver så brugt som min sammensat Clustered key, da alle opslag er specifikt på en server og på den her måde ligger de fysisk tæt på disken og giver bedre performance"

Et clustered index kan jo godt være voldsomt fragmenteret, så data pages ligger spredt over hele den fysiske disk. Et index rebuild ville rydde op i det. Måske et forsøg værd?
Avatar billede Syska Mester
25. august 2009 - 18:37 #4
Hej,

Ikke lock ... er testet.

Rebuild er lavet ... ingen hjælp.

Det viser sig så at jeg ... for gud ved hvor mange dage siden lavede nogen indexes om ... så andre quries blev meget hurtigere. Det havde så den effekt at jeg slettede mine SID_VID index på en anden table som så ikke blev brugt mere ...

Hvad jeg dog ikke tænkte på var at det var et foreign key index jeg slettede ... min anden query bruger SID_EventID og så en masse include columns den så joiner på ...

Hvad jeg så lærte er det ... husk hvad man laver om ...

Men når 1 table joiner over på mange andre tables ... noget ala:

Event table:
EventID ( IDENTITY )
SID
TypeID
FromPlayerID
ToPlayerID
FromAID
ToAID
VillageID

når man så joiner over på de forskellige ID'er ... så foreslår Query Optimizer at lave det som

SID, TypeID og så include resten ... det overraskede mig lidt ... og derfor røg mine andre SID_(FromPlayerID, ToPlayerID) som før var enkelte indexes ... da jeg troede den brugte et index per join ... men det gør den jo så tilsyneladende ik' ...

Så lige nu har jeg 5 GB data ... og 15 GB index ... plads er der nok af ... og delete er hurtig ... men i min verden er det ik' specielt optimalt ... :-s

Hvis du kan give et par gode hints her ... så er jeg super glad.

// ouT
Avatar billede HenrikSjang Nybegynder
25. august 2009 - 19:07 #5
Hvordan er dit brugsmønster på db'en?

altså bliver der lavet mange opslag i tabellen, og/eller mange løbende inserts/updates... og deletes - sker de kun i bulks, eller også løbende i løbet af dagen?

Indexer kan både være gode og dårlige, og ens brugsmønster kan være med til at vurdere om overhead'et i at have mange indexer rent faktisk giver værdi.
Avatar billede Syska Mester
25. august 2009 - 22:05 #6
ja ...

Delete 1 gang om dagen af gamle rows som ikke længere har nogen reel værdi ... så de bliver slettet.

Update 1 gang om dagen med nye stats ...

Så jeg vil næsten mene at det er den rigtige løsning jeg har ...

Dog er jeg lidt forundret over den index løsning der gav den super meget bedre performance. Det betyder jo at for hver table, som bliver brugt, skal man have de totalt rigtige index alt efter hvordan man joiner ... wow. Men logisk set er det vel klart nok, bare ikke noget jeg tidligere har overvejet da det altid har været kæde join ... og ikke mange join fra en table til mange andre.

insert er ikke noget problem. Tror jeg laver ca. 13 mio inserts på ca. 40 mins ... og en masse sammenligninger ... så der tror jeg ikke rigtig der kan laves noget for at gøre det meget bedre. og det er fordelt på ca. 360 servere.

// ouT
Avatar billede Syska Mester
11. marts 2010 - 09:12 #7
Var pga manglende Index ved foreign keys som blev kontrollerret ved delete. Meget mærkeligt, da det ikke har nogen speciel performance hit ved select.
Avatar billede janus_007 Nybegynder
15. marts 2010 - 18:35 #8
Hvis du ikke kører cascading delete så kunne du disable dine constraints når du sletter.

Jeg har selv siddet med store baser, og der kørte jeg med table partitioning, ret smart - har du overvejet det?
Avatar billede Syska Mester
16. marts 2010 - 14:14 #9
Kører ikke med Cascading delete, da jeg gerne selv vil være sikker på at der ikke går noget galt ... og at jeg selv får rydet op.

Jeg har overvejet partionering ... men jeg synes ikke helt jeg kan læse mig frem til hvornår man bruger det ... eller jo ... mest ved store reports ... og så dele ved dato.

Men det kræver vel også at man så opretter flere som tider går ?

Det er i hvert fald noget jeg skal kigge mere på, da mange af mine data reelt set ikke har noget med hinanden at gøre.

400 forskellige ID's .... og alt data med et ID vil aldrig komme til at røre de andre ... i så fald kan jeg gøre det i min kode, hvis det endelig skulle være.
Avatar billede Ny bruger Nybegynder

Din løsning...

Tilladte BB-code-tags: [b]fed[/b] [i]kursiv[/i] [u]understreget[/u] Web- og emailadresser omdannes automatisk til links. Der sættes "nofollow" på alle links.

Loading billede Opret Preview
Kategori
Computerworld tilbyder specialiserede kurser i database-management

Log ind eller opret profil

Hov!

For at kunne deltage på Computerworld Eksperten skal du være logget ind.

Det er heldigvis nemt at oprette en bruger: Det tager to minutter og du kan vælge at bruge enten e-mail, Facebook eller Google som login.

Du kan også logge ind via nedenstående tjenester