Muss ich den eindeutigen Index löschen, wenn ich die Größe einer nvarchar-Spalte ändere? Und wird die Tabelle gesperrt, wenn der Index neu erstellt wird?

In unserer Datenbank gibt es eine große Tabelle, die ungefähr so ​​aussieht:

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

Aber jetzt ist die Größe des seriellen Feldes zu gering geworden, daher möchte ich es auf 32 ändern. Das Visual Studio-Schema-Vergleichstool schlägt vor, dies folgendermaßen zu tun:

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);

Wird das wirklich gebraucht? Oder eher wie ein ultra-sicherer Weg, dies zu tun?

Wird meine Tabelle auch beim erneuten Erstellen des eindeutigen Index gesperrt? Dies wäre ein großes Problem (da die Tabelle 30 Millionen Zeilen enthält und die Neuerstellung des Index vermutlich einige Zeit in Anspruch nimmt), da das nächste Wartungsfenster einige Monate in der Zukunft liegt. Was sind meine Alternativen?

Der Index muss nicht gelöscht und neu erstellt werden.

Benutz einfach

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

Dies ist nur eine Metadatenänderung.

Das Ändern einer Spalte von NVARCHAR(16)bis NVARCHAR(32)wirkt sich überhaupt nicht auf den Speicher aus.

Wenn Sie den umgekehrten Weg (von NVARCHAR(32)bis NVARCHAR(16)) einschlagen, erhalten Sie eine Fehlermeldung, wenn Objekte von der Spalte abhängig sind. Daher generiert Visual Studio möglicherweise nur immer diesen Kesselplattencode, anstatt zu prüfen, ob er tatsächlich erforderlich ist.