Afhankelijk van de wijziging die u aanbrengt, kan het soms gemakkelijker zijn om een onderhoudsperiode te nemen. Tijdens dat venster (waar niemand de gegevens in de tabel mag wijzigen) kunt u:
- laat alle indexen/beperkingen die naar de oude kolom verwijzen weg, en schakel triggers uit
- voeg een nieuwe nullable toe kolom met het nieuwe gegevenstype (zelfs als het NIET NULL is)
- werk de nieuwe kolom bij door deze gelijk te stellen aan de waarde van de oude kolom (en u kunt dit doen in delen van afzonderlijke transacties (bijvoorbeeld 10.000 rijen tegelijk beïnvloeden met behulp van
UPDATE TOP (10000) ... SET newcol = oldcol WHERE newcol IS NULL) en met CHECKPOINT om overschrijding van uw logboek te voorkomen) - zodra alle updates klaar zijn, laat je de oude kolom vallen
- hernoem de nieuwe kolom (en voeg indien van toepassing een NOT NULL-beperking toe)
- indexen opnieuw opbouwen en statistieken bijwerken
De sleutel hier is dat u de update stapsgewijs kunt uitvoeren in stap 3, wat u niet kunt doen in een enkele ALTER TABLE-opdracht.
Dit veronderstelt dat de kolom geen grote rol speelt in de gegevensintegriteit - als deze betrokken is bij een reeks externe-sleutelrelaties, zijn er meer stappen.
BEWERKEN
Ook, en gewoon hardop afvragend, heb ik hier geen tests voor gedaan (maar het aan de lijst toegevoegd). Ik vraag me af of pagina + rijcompressie hier zou helpen? Als u een INT verandert in een BIGINT, moet SQL Server met compressie nog steeds alle waarden behandelen alsof ze nog steeds in een INT passen. Nogmaals, ik heb niet getest of dit een wijziging sneller of langzamer zou maken, of hoeveel langer het zou duren om compressie toe te voegen. Gewoon weggooien.