Jeg har haft kigget lidt på nogen af mine import script og måske fundet nogen flaske halse der måske kan gøre noget ved ... jubiii.
Men da det kun er en gang om dagen og jeg gerne vil vide hvorfor eller hvorfor ik' det vil blive bedre af det.
Følgende sql: MERGE INTO VillageStats AS VS USING ( SELECT [VID], [UID],[Population] FROM Villages WHERE SID = @SID AND Active = 1 ) I([VID], [UID], [Population]) ON (VS.[SID] = @SID AND VS.[VID] = I.[VID] AND VS.[Added] = @DT) WHEN NOT MATCHED THEN INSERT ([SID],[VID],[UID],[Population],[Added]) VALUES (@SID, I.[VID], I.[UID], I.[Population], @DT);
meget for rimelig lidt ... dog er jeg 100% sikker på ikke at få dubleetter af mine entries og ikke at få exceptions hvis der af en eller anden mærkelig grund tidligere skulle være indsat noget.
Men ... men da netop flere af disse tager en del tid at udføre vil jeg selvf gøre have gjort så de kører hurtigere.
Det kommer der selvf nogen spørgsmål ud af ...
Jeg kunne lave noget ala: INSERT INTO VillageStats ([SID], [VID], [UID], [Population], [Added] ) SELECT V.[SID], V.[VID], V.[UID], [V].[Population], @DT AS [Added] FROM Villages V
Mere simple men ingen kontrol hvis data nu findes allerede.
Men til mine egentlig spørgsmål ... System info: Simple Recovery Mode MSSQL 2008 ( 10 ) Der kører 3 kald i min Stored Procedure * 320.
1 spm: Hvis ... er der performance gain ved at smide det hele i en transaction for hver af mine import kald ?
2 spm: Mister jeg meget ved at bruge MERGE ?
Jeg ved at jeg kunne teste det ... men at gøre det kun på 1 af gangen har vist sig ikke helt at holde stik når alle 320 bliver smidt efter den. Derudover er jeg også interesseret i generel performance viden :-) Det kan jo give arbejde en dag man er færdig udd .
Ja. Generelt kan det forbedre performance en smule ved at bundle flere opdateringer i en enkelt transaktion. Men du vil vaere noedt til at skulle maale for at se hvad det giver i dit tilfaelde.
For simple INSERT's (ikke samme problem stilling som din !) saa kan det give en faktor 2-4.
Nej, jeg tror ikke der som sådan er nogen i vejen lige på den front. Jeg henter en masse data ... sådan lidt server efter server og opdatere deraf.
Jeg har overvejet muligheden for måske at kører det hele over en kam til sidst ... det kunne også være en mulighed, dog ved jeg ikke hvor meget der er at vinde. Sidste jeg prøvede med samme taktik gav det samme resultat.
De selects jeg så får lavet bliver kæmpe store ... vi snakker nok 20.000 * 320 = 6.400.000 rows der skal køres i en transaction så.
Derfor jeg ikke er helt sikker på at jeg kan vinde noget ved det, men du kan sikkert overbevise mig om andet :-)
Jeg søger, lærer og læser :-) SQL er et spændende emne.
I dit tilfælde tror jeg ikke det kan betale sig at putte det hele ind i en transaktion. Man skal også passe på at transaktioner ikke bliver alt for store, da det koster memory.
Med hensyn til din merge: Merge i SQL Serveren har rimelig god performance. Jeg tror ikke du vil få noget ud af, og lave noget som ikke bruger merge. Der du måske kan opnå en forbedring, er ved at køre alle opdateringer i en query, hvis det kan lade sig gøre. Det er dog svært at sige noget mere specifikt, da jeg ikke kender din database godt nok.
Sad og testede lidt på det i går ... mener at de estimated cost var højere ved INSERT INTO () SELECT FROM og lavere ved MERGE INTO.
Mærkeligt nok ... MERGE INTO havde et lavere IO cost ... jeg skal vist have set lidt mere på de Execution plans ...
Undrede mig egentlig mest over at man ikke kunne få en samlet oversigt over en hel Execution plan, så det var nemmere at se forskellige ... det eneste som for mig giver en ide om den % del som bliver udskrevet.
Altså hvad der eventuelt tager mest CPU tid ... IO cost og alle de andre parameter for en hel batch :-)
Så for mig at se ... håber dog jeg har overset noget er det næsten umuligt lige hurtigt at få et overblik over hvad der egentlig er bedst.
// ouT
Synes godt om
Ny brugerNybegynder
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.
