Будет ли обновление от INT до BIGINT для многораздельной таблицы отличаться от обновления? - PullRequest
Новая
       26

Будет ли обновление от INT до BIGINT для многораздельной таблицы отличаться от обновления?

0 голосов
/ 16 мая 2018

Мне нужно обновить столбец индекса идентификатора первичного ключа таблицы со INT до BIGINT.

Справочная информация:

  • Столбец является столбцом идентификаторов
  • Столбец является первичным ключом
  • Индекс является кластеризованным индексом
  • Таблица секционирована
  • В настоящее время имеется 111 разделов
  • Этостолбец, на котором таблица разбита на разделы
  • Занимает чуть менее 1 ТБ пространства данных
  • Занимает чуть менее 400 ГБ пространства индекса
  • Фактическое число строк составляет чуть менее 1,4 Б строкно приращение идентификатора выше, так как некоторые строки были удалены
  • В настоящее время это SQL Server 2008 R2, но планируется установить его на SQL Server 2016 во время изменения
  • Их более 40внешние ключи в других таблицах, ссылающихся на этот столбец
  • Очевидно, что, поскольку он разбит на разделы, это Enterprise Edition
  • Строки довольно широкие с 81 другим столбцами
  • Я хотел бы минимизироватьКак можно больше
  • Значения не могут измениться из-за внешнего ключа 40+, но также есть много значений, вставленных вручную в другие таблицы, которые не имеют отношения FK.
  • У меня естьНекоторое количество дополнительного пространства, с которым я могу работать, есть много, но работая с общим объемом файлов более 100 ТБ, я должен быть осторожен
  • Я могу сделать это в окне обслуживания

Мой текущий план состоит в том, чтобы использовать процесс, описанный в https://dba.stackexchange.com/a/159251/44556 и подробно рассмотренный Аароном Бертраном здесь: https://sqlperformance.com/2016/08/sql-indexes/widening-identity-column-4

У меня есть вопросы :

  1. Могу ли я использовать процесс, описанный в приведенной выше ссылке?
  2. Нужно ли будет отличаться этот процесс, учитывая, что в этом столбце есть многораздельная таблица?
  3. Что еще нужно знатьиз?
  4. Есть ли какой-нибудь альтернативный процесс, который я мог бы рассмотреть, который был бы лучше?Если так, то почему это лучше?

Существует множество сообщений о том, как выполнить процесс обновления, но я не заметил ни одной, ссылающейся на секционированные таблицы.

Фрагментопределения таблицы: (искусственно модифицированный для защиты невинных) Обратите внимание, что это SQL Server 2008 R2, до обновления до 2016 года 

SET ANSI_NULLS ON
GO
SET QUOTED_IDENTIFIER ON
GO
SET ANSI_PADDING ON
GO

CREATE TABLE [dbo].[MyDataRecord]
(
    [JMyDataRecord_ID] [int] IDENTITY(1,1) NOT FOR REPLICATION NOT NULL,
    ... 81 other columns
    CONSTRAINT [PK_MyDataRecord_ID] 
        PRIMARY KEY CLUSTERED ([MyDataRecord_ID] ASC)
)
... other stuff like FK etc

1 Ответ

0 голосов
/ 17 мая 2018

Я могу выглядеть не как решение, а скорее как альтернативный метод.

Обычно необходимость обновить ключи INT до BIGINT - это когда значения ключей приближаются к максимальному значению int (2 147 483 647).В вашем случае у вас все еще есть место для роста, и вы можете расширить его с небольшими затратами, перезадав ключи до минимального отрицательного числа: -2 147 483 648, так что у вас будет достаточно времени, пока он не достигнет нуля.И в случае, если вы периодически архивируете данные, вам, возможно, никогда не потребуется менять их на BIGINT.

RESEED - очень быстрая и простая команда без каких-либо недостатков, без простоев.Вам просто нужно проверить, есть ли у вас какая-либо логика приложения, основанная на сравнении ключей, например> =, <=, ORDER BY и т. Д. Даже в таких случаях довольно легко исправить эту логику. </p>

...