Czy przy zmianie rozmiaru kolumny nvarchar muszę usunąć unikalny indeks? I czy tabela zostanie zablokowana podczas odtwarzania indeksu?

14

W naszej bazie danych istnieje duża tabela, która mniej więcej wygląda tak:

CREATE TABLE dbo.production_data
(
    pd_id BIGINT PRIMARY KEY,
    serial NVARCHAR(16) NOT NULL UNIQUE,
    ...
);

ale teraz rozmiar pola szeregowego stał się zbyt niski, więc chcę go zmienić na 32. Narzędzie porównywania schematów programu Visual Studio sugeruje wykonanie tego przez:

DROP INDEX ux_production_data_serial ON dbo.production_data;
GO
ALTER TABLE dbo.production_data ALTER COLUMN serial NVARCHAR(32) NOT NULL;
GO
CREATE INDEX ux_production_data_serial ON dbo.production_data(serial ASC);

Czy to jest naprawdę potrzebne? A może bardziej bezpieczny sposób na zrobienie tego?

Czy podczas tworzenia unikalnego indeksu moja tabela zostanie zablokowana? Ponieważ byłby to duży problem (ponieważ tabela ma 30 milionów wierszy i myślę, że odtworzenie indeksu zajmie sporo czasu), ponieważ następne okno konserwacji będzie miało kilka miesięcy w przyszłości. Jakie są moje alternatywy?

Staeff
źródło

Odpowiedzi:

24

Nie ma potrzeby upuszczania i ponownego tworzenia indeksu.

Po prostu użyj

ALTER TABLE dbo.production_data
  ALTER COLUMN serial NVARCHAR(32) NOT NULL; 

Jest to zmiana tylko dla metadanych.

Zmiana kolumny z NVARCHAR(16)na w NVARCHAR(32)ogóle nie wpływa na pamięć.

Odwrotne odwrócenie (od NVARCHAR(32)do NVARCHAR(16)) dałoby ci błąd dotyczący zależności obiektów od kolumny, więc może Visual Studio zawsze generuje ten kod płyty kotłowej zamiast sprawdzać, czy jest rzeczywiście wymagany.

Martin Smith
źródło
2
Ciekawe, dlaczego program Visual Studio pisze to jako DROP / CREATE INDEX. Prawdopodobnie niepotrzebna, bezwarunkowa CYA.
Aaron Bertrand
2
@AaronBertrand - Przypuszczam, że to tylko brakująca optymalizacja dla przypadków, w których nie jest wymagana. Książki online wskazały, że było to potrzebne w kilku przypadkach, w których produkt tak naprawdę nie wymagał aż do tej aktualizacji
Martin Smith,