Verbeter de update-prestaties bij het instellen van de kolom op null

Een beetje lang hier, maar ik heb hieronder een eenvoudige vraag:

begin transaction       

update s
set s.SomeField = null
from someTable s (NOLOCK)

rollback transaction

Dit loopt in ~ 30 seconden dicht bij de SQL Server-box. Zijn er trucs die ik kan gebruiken om de snelheid te verbeteren. De tabel bevat 144,306 rijen.

bedankt.

1
Ja, het maakt deel uit van een index. Rollback voegt ongeveer 10 seconden meer tijd toe. Nog steeds lijkt 20 seconden te veel.
toegevoegd de auteur O.O, de bron
@Martin - Oké.
toegevoegd de auteur O.O, de bron
@Tony - dit wordt alleen gedaan wanneer er geen gebruikers op het systeem zijn.
toegevoegd de auteur O.O, de bron
@dasblinkenlight - geen triggers.
toegevoegd de auteur O.O, de bron
Is SomeField deel van een index? Wat gebeurt er als je niet terugdraait? Neemt rollback het grootste deel van de tijd in beslag, of is het de uitschakeling?
toegevoegd de auteur dasblinkenlight, de bron
@ subt13 Nog een snelle vraag: heb je triggers die worden uitgevoerd wanneer je die tabel bijwerkt? Waarschijnlijk niet, maar ik dacht dat ik het toch wel zou kunnen vragen.
toegevoegd de auteur dasblinkenlight, de bron
Als dit een gewone manouvre is, moet je naar je schema kijken of de prijs betalen. Elke betrokken index + de tabel en waarschijnlijk zullen de indexen ook verstopt raken ..
toegevoegd de auteur Tony Hopkinson, de bron
van someTable s (NOLOCK) is volkomen zinloos. Het zal de hoeveelheid vergrendeling niet verminderen, gebruik gewoon update someTable set SomeField = null
toegevoegd de auteur Martin Smith, de bron

5 antwoord

De grootste component van de uitvoering van een grote UPDATE-opdracht als deze is de snelheid van uw DB-logboek.

Voor de beste prestaties:

  1. Zorg ervoor dat het DB-logbestand (LDF-bestand) zich op een afzonderlijke fysieke spil bevindt van de DB-gegevens (MDF-bestand)
  2. Vermijd pariteit RAID voor het logboekvolume, zoals RAID-5; RAID-1 of RAID-10 zijn beter
  3. Controleer of het DB-logboekbestand vooraf is gegroeid en of het fysiek aaneengesloten is op de schijf
  4. Zorg ervoor dat uw server voldoende RAM heeft - in het ideale geval minstens genoeg om alle DB-pagina's met de gewijzigde rijen te bevatten

Het gebruik van SSD's voor je datadrive kan ook helpen, omdat het commando een groot aantal vuile buffers zal creëren, die later door de luie schrijver naar de schijf worden doorgespoeld; dit kan andere bewerkingen op de DB langzaam maken terwijl het gebeurt.

2
toegevoegd

U zou de syntaxis van uw vraag enigszins kunnen veranderen, maar ik had geen verschil in mijn testen door dat te doen. Ik gebruikte STATISTICS IO en STATISTICS TIME .

You mention the column is indexed. You could disable it/re-enable it as part of your transaction. The t-sql for that is simple, see this - http://blog.sqlauthority.com/2007/05/17/sql-server-disable-index-enable-index-alter-index/

In het verleden moest ik dat doen voor vergelijkbare banen en het heeft goed uitgepakt voor mij.

1
toegevoegd
1
toegevoegd
Slechte uitschakeling/reconstructie (enkele seconden) verbeterde de prestaties.
toegevoegd de auteur O.O, de bron
@MartinSmith Dat is absoluut correct. Het opnieuw opbouwen van een index kan echter goedkoper blijken te zijn dan het mixen van updates aan de index met updates voor de tabel. Ik zeg niet dat het noodzakelijkerwijs een verbetering zou opleveren, maar het heeft voldoende kans om het te proberen.
toegevoegd de auteur dasblinkenlight, de bron
opnieuw inschakelen betekent dat de indexen opnieuw moeten worden opgebouwd.
toegevoegd de auteur Martin Smith, de bron

Als er geen beperking is, en je moet echt alle waarden van die kolom instellen op NULL, dan zou ik testen de kolom laten vallen en opnieuw toevoegen.

Ik weet niet zeker of dat sneller zou zijn of niet, maar ik zou het onderzoeken.

1
toegevoegd
Goed idee, daar zal ik naar kijken.
toegevoegd de auteur O.O, de bron
Niet gaan werken. Deze kolom wordt door verschillende indexen gerefereerd. Laat de indexen hiervoor niet vallen en maak ze opnieuw. Dat zou nog langer duren.
toegevoegd de auteur O.O, de bron

Probeer het zo te implementeren

Disable Index

Drop the column
Create the column

Rebuild index

Ik kan wel raden dat dit de prestaties zal verbeteren.

0
toegevoegd
Hoe verschilt dit van de bovenstaande antwoorden naast de ogenschijnlijk extra overhead van het laten vallen/maken van zowel de kolom als de indexen?
toegevoegd de auteur O.O, de bron