По материалам статьи: Michael R. Hotek "
Architecting replication with identity columns"
Автор статьи очень часто встречает вопросы о том, что
использование поля identity порождает проблемы в репликации.
Но он убеждён, что колонка Identity вполне может быть
использована в репликации, просто необходимо выполнить
некоторое предварительное планирование, наряду с установкой
редко используемой опции. Эта статья описывает хороший метод,
который автор использовал несколько лет, и который позволил
ему успешно использовать колонки identity.
Во-первых, Вы
всегда должны управлять значениями колонки identity, если
вставка данных происходит более чем в одной базе данных,
участвующих в репликации. Когда в первой базе вставляется в
качестве значения для identity единица, во второй базе также
должно вставляться значение identity равное 1, и при этом
должна успешно выполняться проверка на пересечение. Это
означает, что должна гарантироваться уникальность нового
значения identity в каждой базе данных.
Для тиражирования
данных столбца identity, репликация делает явную вставку в
такой столбец. Это выполняется инструкцией identity_INSERT,
которая вставляет в столбец identity новое значение. Вы должны
быть внимательны, т.к. единственной причиной в репликации,
из-за которой возникают проблемы, это то, как столбец identity
ведет себя при вставке. Когда происходит вставка записи, в
столбец identity записывается значение, которое на единицу
больше, чем максимальное значение для этого столбца. Это может
повредить репликации, т.к. при каждом её сеансе значения
колонки identity для новых записей будут заменяться на другие,
рассчитанные для получаемой реплицируемые данные таблицы
(reseeded). Эти новые значения могут нарушить ограничения
первичного ключа. Поэтому, в репликации можно отключить
пересчёт значений столбца identity, просто используя
предложение "not for replication" для реплицируемых identity
столбцов. Выглядит это примерно так:
create table mytable
(Col1 int identity (1,1) not
for replication not null
<другие поля
таблицы>
Таким образом, Вы сообщите серверу баз данных, что
необходимо отключить код, который повторно пересчитывает
столбец identity, когда агент репликации вставляет данные в
столбец identity. При этом сохраняются диапазоны identity,
которые были установлены. Недостаток этой опции состоит в том,
что в SQL Server 2000 Вы не можете добавлять эту опцию путём
изменения, вносимого в публикуемую таблицу. Встречаются
некоторые предложения по изменению для этого системных таблиц,
которые автор не хочет рассматривать в рамках этой статьи. Не
пробуйте устанавливать эту опцию путём изменения системных
таблиц, если Вы не хотите потратить ваше время на
восстановление базы данных из резервной копии, поскольку это
может привести к повреждению базы данных. Наиболее
безболезненным способом включения опции "not for replication"
является исполнение представленного ниже алгоритма:
1) Переименуйте таблицу, в которую нужно добавить
опцию.
2) Создайте новую таблицу с прежним именем и
включённой опцией.
3) Вставьте данные из переименованной
таблицы в новую.
4) Проверьте, что данные не
повреждены.
5) Удалите переименованную таблицу.
Теперь, когда мы выяснили, как предотвратить пересчёт
столбца identity при работе агента репликации, остался только
один вопрос: как разделить диапазоны значений колонки identity
для разных баз данных. Есть очень простой метод, которым автор
пользовался несколько лет.
Большинство DBA используют
целочисленный тип данных для identity. Однако, немногие
используют тот факт, что целое число может быть и
положительным и отрицательным. Использование же обоих
диапазонов положительных и отрицательных значений очень
простым способом расширяет возможности
репликации.
Представленные ниже примеры сценариев кратко
дают представление о том, как автор первоначально выделял
разделы диапазонов значений identity, и как они расширялись по
мере увеличения количества баз данных, участвующих в
репликации.
Порядковый
номер базы
данных |
Начальное
значение
identity |
Приращение
identity |
Примечание |
| 2 базы данных |
| 1 |
1 |
2 |
нечётные, положительные числа |
| 2 |
2 |
2 |
чётные, положительные числа |
| 4 базы данных |
| 1 |
1 |
2 |
нечётные, положительные числа |
| 2 |
2 |
2 |
чётные, положительные числа |
| 3 |
-1 |
2 |
нечётные, отрицательные числа |
| 4 |
-2 |
2 |
чётные, отрицательные числа |
| 8 баз данных |
| 1 |
1 |
2 |
нечётные, положительные числа |
| 2 |
2 |
2 |
чётные, положительные числа |
| 3 |
-1 |
2 |
нечётные, отрицательные числа |
| 4 |
-2 |
2 |
чётные, отрицательные числа |
| 5 |
500,000,001 |
2 |
нечётные, положительные числа,
начинающиеся с полмиллиарда + 1 |
| 6 |
500,000,002 |
2 |
чётные, положительные числа |
| 7 |
-500,000,001 |
2 |
нечётные, отрицательные числа |
| 8 |
-500,000,002 |
2 |
чётные, отрицательные числа |
| 16 баз данных |
| 1 |
1 |
2 |
нечётные, положительные числа |
| 2 |
2 |
2 |
чётные, положительные числа |
| 3 |
-1 |
2 |
нечётные, отрицательные числа |
| 4 |
-2 |
2 |
чётные, отрицательные числа |
| 5 |
500,000,001 |
2 |
нечётные, положительные числа |
| 6 |
500,000,002 |
2 |
чётные, положительные числа |
| 7 |
-500,000,001 |
2 |
нечётные, отрицательные числа |
| 8 |
-500,000,002 |
2 |
чётные, отрицательные числа |
| 9 |
1,000,000,001 |
2 |
нечётные, положительные числа |
| 10 |
1,000,000,002 |
2 |
чётные, положительные числа |
| 11 |
-1,000,000,001 |
2 |
нечётные, отрицательные числа |
| 12 |
-1,000,000,002 |
2 |
чётные, отрицательные числа |
| 13 |
1,500,000,001 |
2 |
нечётные, положительные числа |
| 14 |
1,500,000,002 |
2 |
чётные, положительные числа |
| 15 |
-1,500,000,001 |
2 |
нечётные, отрицательные числа |
| 16 |
-1,500,000,002 |
2 |
чётные, отрицательные
числа |
Основная идея состоит в том, чтобы при добавлении новых баз
данных в схему репликации, разбивать диапазоны identity на
чётные/нечётные, которые в свою очередь разбивать на
положительные/отрицательные. Когда Вы включаете в систему
репликации 4 базы данных, Вы просто разбиваете каждый диапазон
напополам. Вы продолжаете это разбиение, по мере добавления
баз данных. Для большого количества баз данных, такой алгоритм
разбиения может стать проблематичным. Для случаев, когда
количество баз превышает 500, автор просто использует для
identity тип данных decimal, потому что он обеспечивает более
широкий диапазон значений, что облегчает разделение диапазонов
identity.
В SQL Server 2000 многие задачи по настройке были
автоматизированы. Всё, что Вы должны сделать, это при
установке назначить диапазоны для подписчиков, а затем
репликация будет управлять ими сама. Она будет делать это,
позволяя Вам определять пороговые значения для identity.
Нормальные значения будут вставляться репликацией в вашу
identity колонку. Когда значение identity достигнет
определённого Вами порога, репликация переопределит identity в
следующий, более высокий, допустимый диапазон значений. Хотя в
ваших значениях и могут оставаться промежутки, Вам больше не
нужно будет управлять всеми диапазонами identity. И не
забывайте включить опцию SQL Server 2000: "not for
replication".
[В начало]
|