Я использую SQL Server 2008, и у меня есть таблица, содержащая около 50 рядов мельниц.
В этой таблице содержится первичный столбец идентификатора типа int.
Я хочу обновить этот столбец до bigint.
Мне нужно знать, как сделать это быстрым способом, который не сделает мой сервер БД недоступным, и не будет удалять или разрушать любые мои данные.
Как мне лучше всего это сделать? каковы последствия этого?
Ну, это не быстрый способ сделать это, правда....
Мой подход будет таким:
создать новую таблицу с одинаковой структурой - кроме столбца ID, являющегося BIGINT IDENTITY вместо INT IDENTITY
---- [помещает ваш сервер в эксклюзивный однопользовательский режим здесь; пользователь не может использовать ваш сервер с этого момента] ----
найти и отключить все ограничения внешнего ключа, ссылающиеся на вашу таблицу
turn SET IDENTITY_INSERT (your new table) ON
вставьте строки из старой таблицы в новую таблицу
turn SET IDENTITY_INSERT (your new table) OFF
удалить свою старую таблицу
переименуйте новую таблицу в имя старой таблицы
обновите всю таблицу, которая имеет ссылку FK для вашей таблицы, чтобы использовать BIGINT вместо INT (это должно выполняться с помощью простого ALTER TABLE ..... ALTER COLUMN FKID BIGINT)
снова создайте все отношения с внешним ключом
теперь вы можете снова вернуть свой сервер в обычное многопользовательское использование
Что мне не хватает?
Почему вы не можете просто сделать это:
ALTER TABLE tableName ALTER COLUMN ID bigint
Я предполагаю сначала попробовать его в тестовой среде, но это всегда работает для меня.
Вероятно, лучший способ - создать новую таблицу с столбцом BIGINT IDENTITY, переместить существующие данные, используя SET IDENTITY_INSERT ON; а затем переименуйте таблицы. Вам нужно будет сделать это во время окна обслуживания, как если бы вы изменили тип данных в Management Studio (который аналогичным образом создаст новую таблицу, переместит данные и заблокирует всех в процессе).
Почему кто-то хочет использовать BigInt вместо Int как IDENTITY?
Рассмотрим этот сценарий: Ваша база данных существует в нескольких средах, включая 1 экземпляр в живой производственной среде и нескольких других экземплярах (TestA, B, C и т.д.), (QA A, B, C и т.д.), (Демо A, B, C, и т.д.), (UAT A, B, C и т.д.), (обучение A, B, C и т.д.) дальше и дальше... Вы даже не хотите знать...
Это поле IDENTITY базы данных используется для передачи уникального номера стороннему поставщику, который является общей средой в средах Non Production. Поставщик заряжает руку и ногу, чтобы настроить несколько сред, поэтому у компании есть одна для производственной БД и одна для ВСЕХ других.
Итак... когда тестирование происходит в не производственных средах, эти цифры никогда не могут пересекать друг друга из любой другой производственной среды, в которой вы тестируете. И тестирование включает стресс-тестирование... отправку 100 тысяч строк в время.
В довершение всего... ВСЕ эти среды обновляются с помощью Production, поэтому поле Identity получает reset с тем, что было в производстве. Поэтому нужно следить за тем, какой спред был использован в каждой среде, а затем reset ИДЕНТИФИКАЦИЯ к новому спреду, который никогда не использовался раньше. Сторонний поставщик будет блевать, если в этих средах снова будет отправлено уже число. И продавец не желает или не может обновить или reset эти номера на конце.
Это проблема реального мира, и текущее поле по-прежнему остается int во всех средах, и управление отслеживанием этих спредов обновляется каждый квартал или всякий раз, когда кто-то делает массовое стресс-тестирование 100 тысяч транзакций.
Итак, примерно через 10 лет эта ИДЕНТИФИКАЦИЯ должна быть обновлена до BIGINT, или кто-то должен будет убедить стороннего поставщика обновить их конец.
О, да, менеджмент может дать крысу задницу, пока все не рухнет внезапно.
Затем HACK "ALTER TABLE tableName ALTER COLUMN ID bigint" будет отлично работать. Обработка пространства и индекса - это CHEAP!