Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Microsoft SQL Server Новый топик    Ответить
Топик располагается на нескольких страницах: [1] 2   вперед  Ctrl      все
 Какие неприятности при регулярной коррекции автоинкрементного поля  [new]
vladK
Member

Откуда: Харьков
Сообщений: 828
Подскажите, какие сюрпризы с таблицей могут меня ждать, если я манипулирую её автоинкрементным полем, для целей синхронизации с SQL Azure, следующим образом:

if OBJECT_ID('tempdb..#t') IS NOT NULL 
	DROP TABLE #t
go	
--локальная таблица
create table #t (
	id int identity(1,1) primary key nonclustered,	
	a varchar(10)
	);	
--локальные вставки с id по умолчанию
insert into #t values('a'),('b')

--синхронизация
	--HUB-->LOC: 
	    -- перенес записи на локальный сервер 
	SET IDENTITY_INSERT #t ON
		--вставил  записи с облачными id ( > 100)
		insert into #t(id, a) values(100, 'c'),(101, 'd')		
	SET IDENTITY_INSERT #t OFF
--конец синхронизации

--надо продолжить локальные вставки, в локальнои диапазоне id:[1;100)
Declare @LastLocID int = (select max(id) from #t where id < 100); --послений ID локальных вставок
DBCC CHECKIDENT ('#t', RESEED,  @LastLocID) -- сбрасываем identity !!!

--продолжаем вставки локально
insert into #t values('e'),('f')
insert into #t values('g'),('h')

DBCC CHECKIDENT ('#t', NORESEED)--проверка

select * from #t

Checking identity information: current identity value '101', current column value '2'.

Checking identity information: current identity value '6', current column value '101'.

id a
----------- ----------
1 a
2 b
100 c
101 d
3 e
4 f
5 g
6 h

Синхронизация будет 1 раз в день. Таким образом будет добавляться не больше десятка записей в 5-6 таблиц.
Кол-во записей в таблицах: только в одной близко к 100 000, в остальных меньше 10 000.

Понятно, что по хорошему автоинкременты надо убирать, но они завязаны в нескольких приложениях, трогать их не хотелось бы.
20 окт 15, 12:51    [18302105]     Ответить | Цитировать Сообщить модератору
 Re: Какие неприятности при регулярной коррекции автоинкрементного поля  [new]
Glory
Member

Откуда:
Сообщений: 104751
vladK
Подскажите, какие сюрпризы с таблицей могут меня ждать, если я манипулирую её автоинкрементным полем

Это вы про временную таблицу спрашиваете ?
20 окт 15, 12:54    [18302123]     Ответить | Цитировать Сообщить модератору
 Re: Какие неприятности при регулярной коррекции автоинкрементного поля  [new]
vladK
Member

Откуда: Харьков
Сообщений: 828
Glory
Это вы про временную таблицу спрашиваете ?


Нет, временная для демонстрации. Реально будет 5-6 постоянных таблиц, где нужно такое проделывать.
20 окт 15, 12:57    [18302132]     Ответить | Цитировать Сообщить модератору
 Re: Какие неприятности при регулярной коррекции автоинкрементного поля  [new]
Winnipuh
Member [заблокирован]

Откуда: Київ
Сообщений: 10428
vladK
Glory
Это вы про временную таблицу спрашиваете ?


Нет, временная для демонстрации. Реально будет 5-6 постоянных таблиц, где нужно такое проделывать.


смелое решение
20 окт 15, 12:58    [18302140]     Ответить | Цитировать Сообщить модератору
 Re: Какие неприятности при регулярной коррекции автоинкрементного поля  [new]
vladK
Member

Откуда: Харьков
Сообщений: 828
Winnipuh
смелое решение

Сам чувствую что смелое, поэтому решил посоветоваться.
20 окт 15, 13:01    [18302155]     Ответить | Цитировать Сообщить модератору
 Re: Какие неприятности при регулярной коррекции автоинкрементного поля  [new]
Glory
Member

Откуда:
Сообщений: 104751
vladK
Glory
Это вы про временную таблицу спрашиваете ?


Нет, временная для демонстрации. Реально будет 5-6 постоянных таблиц, где нужно такое проделывать.

И как вы собрались обрабатывать добавление дубликатов ?
20 окт 15, 13:09    [18302208]     Ответить | Цитировать Сообщить модератору
 Re: Какие неприятности при регулярной коррекции автоинкрементного поля  [new]
DaniilSeryi
Member

Откуда:
Сообщений: 1978
vladK,

Сделайте два поля - одно автоинкремент для внутреннего употребления (и не трогайте его), второе - int или bigint - для связи с azure, и издевайтесь над вторым как душе угодно.
20 окт 15, 13:09    [18302211]     Ответить | Цитировать Сообщить модератору
 Re: Какие неприятности при регулярной коррекции автоинкрементного поля  [new]
Akina
Member

Откуда: Зеленоград, Москва, Россия
Сообщений: 21249
Вставьте "неурочные" значения не 100 и 101, а поменьше (скажем, 10 и 11), а потом доберитесь до тех же значений "плановым" порядком. Сюрпризы вылезут сами.
20 окт 15, 13:16    [18302282]     Ответить | Цитировать Сообщить модератору
 Re: Какие неприятности при регулярной коррекции автоинкрементного поля  [new]
vladK
Member

Откуда: Харьков
Сообщений: 828
Glory
И как вы собрались обрабатывать добавление дубликатов ?


Проблемы дубликатов здесь не будет, т.к. на удаленном скл сервере ID всех синхронизируемых таблиц, этим же DBCC CHECKIDENT, будет установлено в значение, находящемся за порогом тех, до которых локальные ID, своим обычным identity(1,1) доберутся в обозримом будущем.

Прекрасно понимаю, уязвимость таких утверждений, и сам разгребал базы, где на это понадеялись. Но это не тот подвох, который я здесь ожидаю.

Что то из области:
Могут таблицы "крашится" от этого ?
Статистики лучше персичтывать обязательно с FULL SCAN ?
20 окт 15, 13:36    [18302412]     Ответить | Цитировать Сообщить модератору
 Re: Какие неприятности при регулярной коррекции автоинкрементного поля  [new]
Glory
Member

Откуда:
Сообщений: 104751
vladK
Проблемы дубликатов здесь не будет, т.к. на удаленном скл сервере ID всех синхронизируемых таблиц, этим же DBCC CHECKIDENT, будет установлено в значение, находящемся за порогом тех, до которых локальные ID, своим обычным identity(1,1) доберутся в обозримом будущем.

Я про дубликаты при ваших инсертах
insert into #t(id, a) values(100, 'c'),(101, 'd')
20 окт 15, 13:38    [18302428]     Ответить | Цитировать Сообщить модератору
 Re: Какие неприятности при регулярной коррекции автоинкрементного поля  [new]
Winnipuh
Member [заблокирован]

Откуда: Київ
Сообщений: 10428
vladK
Winnipuh
смелое решение

Сам чувствую что смелое, поэтому решил посоветоваться.


А может SEQUENCE?
20 окт 15, 13:46    [18302485]     Ответить | Цитировать Сообщить модератору
 Re: Какие неприятности при регулярной коррекции автоинкрементного поля  [new]
vladK
Member

Откуда: Харьков
Сообщений: 828
Glory
Я про дубликаты при ваших инсертах
insert into #t(id, a) values(100, 'c'),(101, 'd')

Откуда им взяться:
if OBJECT_ID('tempdb..#t') IS NOT NULL 
	DROP TABLE #t
go	
-- таблица на удаленном сервере - её определение является копией локальной
create table #t (
	id int identity(1,1) primary key nonclustered,	
	a varchar(10)
	);
-- делаю это чтобы разграничить	диапазоны. Для удаленной таблицы id>=100
DBCC CHECKIDENT ('#t', RESEED,  100)	
-- работа приложения с удаленным сервером
insert into #t values('c'),('d')
select * from #t
-- дальше перелив в локальную таблиц
20 окт 15, 13:51    [18302524]     Ответить | Цитировать Сообщить модератору
 Re: Какие неприятности при регулярной коррекции автоинкрементного поля  [new]
vladK
Member

Откуда: Харьков
Сообщений: 828
Winnipuh
А может SEQUENCE?

Надо почитать, но локальная база на sql 2000. И даже если это решаемо, то переделка приложений наверняка нужна будет.
20 окт 15, 13:55    [18302563]     Ответить | Цитировать Сообщить модератору
 Re: Какие неприятности при регулярной коррекции автоинкрементного поля  [new]
Glory
Member

Откуда:
Сообщений: 104751
vladK
Откуда им взяться:

Из таблицы. Или вы ее каждый раз создаете ?
20 окт 15, 14:03    [18302630]     Ответить | Цитировать Сообщить модератору
 Re: Какие неприятности при регулярной коррекции автоинкрементного поля  [new]
Winnipuh
Member [заблокирован]

Откуда: Київ
Сообщений: 10428
vladK
Winnipuh
А может SEQUENCE?

Надо почитать, но локальная база на sql 2000. И даже если это решаемо, то переделка приложений наверняка нужна будет.


не.

а база больше 10 гб?
20 окт 15, 14:05    [18302647]     Ответить | Цитировать Сообщить модератору
 Re: Какие неприятности при регулярной коррекции автоинкрементного поля  [new]
vladK
Member

Откуда: Харьков
Сообщений: 828
Glory
Из таблицы. Или вы ее каждый раз создаете ?

Не понимаю. Намекаете на то что DBCC CHECKIDENT ('#t', RESEED, 100) как собъет мне ожидаемое поведение определения столбца id int identity(1,1) ?

Ну вот после последнего скрипта с удаленной таблицей делаю
insert into #t values('i'),('j')

И в итоге, на удаленном сервере получаю:
id          a
----------- ----------
100 c
101 d
102 i
103 j
20 окт 15, 14:12    [18302690]     Ответить | Цитировать Сообщить модератору
 Re: Какие неприятности при регулярной коррекции автоинкрементного поля  [new]
Glory
Member

Откуда:
Сообщений: 104751
vladK
Не понимаю. Намекаете на то что DBCC CHECKIDENT ('#t', RESEED, 100) как собъет мне ожидаемое поведение определения столбца id int identity(1,1) ?

Я прямо говорю, что вы не знаете, какие значения у вас в таблице содержатся перед тем, как вы начнете туда что-то добавлять
А primary key не позволит вам добавить дубликат
20 окт 15, 14:14    [18302702]     Ответить | Цитировать Сообщить модератору
 Re: Какие неприятности при регулярной коррекции автоинкрементного поля  [new]
vladK
Member

Откуда: Харьков
Сообщений: 828
Winnipuh
база больше 10 гб

до 100M, прирост 1M в месяц
20 окт 15, 14:16    [18302711]     Ответить | Цитировать Сообщить модератору
 Re: Какие неприятности при регулярной коррекции автоинкрементного поля  [new]
vladK
Member

Откуда: Харьков
Сообщений: 828
Glory
Я прямо говорю, что вы не знаете, какие значения у вас в таблице содержатся перед тем, как вы начнете туда что-то добавлять

Прошу прощения, наверное ввел в заблуждение строка первом скрипте
insert into #t(id, a) values(100, 'c'),(101, 'd')

На самом деле, это я показал как записи переливаются из удаленного источника, на локальный. Явные ID я нигде прописывать не буду. Написан SSIS c Inc Load, который возьмет все новые ID c удаленного и перельет в локальный.
20 окт 15, 14:26    [18302793]     Ответить | Цитировать Сообщить модератору
 Re: Какие неприятности при регулярной коррекции автоинкрементного поля  [new]
Glory
Member

Откуда:
Сообщений: 104751
vladK
На самом деле, это я показал как записи переливаются из удаленного источника, на локальный. Явные ID я нигде прописывать не буду. Написан SSIS c Inc Load, который возьмет все новые ID c удаленного и перельет в локальный.

Вы тупите
Еще раз "вы не знаете, какие значения у вас в таблице содержатся перед тем, как вы начнете туда что-то добавлять"
20 окт 15, 14:28    [18302811]     Ответить | Цитировать Сообщить модератору
 Re: Какие неприятности при регулярной коррекции автоинкрементного поля  [new]
Winnipuh
Member [заблокирован]

Откуда: Київ
Сообщений: 10428
vladK
Winnipuh
база больше 10 гб

до 100M, прирост 1M в месяц


ну тогда: почему бы не поставить экспресс 2012 или 2014
20 окт 15, 14:37    [18302901]     Ответить | Цитировать Сообщить модератору
 Re: Какие неприятности при регулярной коррекции автоинкрементного поля  [new]
DROP TABLE #t
Guest
vladK,

или где-то в одном месте должны быть "главные ID", которые проливаются затем во все локальные хранилища, в которых при этом живут свои суррогаты, которые никто не трогает.

или опять же в одном месте должен быть механизм раздачи диапазонов и каждое локальное хранилище в случае приближения к концу своего диапазона должно запрашивать новый у "центра"
20 окт 15, 15:22    [18303225]     Ответить | Цитировать Сообщить модератору
 Re: Какие неприятности при регулярной коррекции автоинкрементного поля  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 31983
vladK
Подскажите, какие сюрпризы с таблицей могут меня ждать, если я манипулирую её автоинкрементным полем, для целей синхронизации с SQL Azure, следующим образом
В данном случае слова "SQL Azure" лишние, я думал, тут про какие то особенности работы с ним :-)

Вопрос в том, можно ли сделать распределённую базу из двух нераспределённых, не меняя код, разделив инкрементные ИД по диапазонам, и делая синхронизацию вставками с включённым SET IDENTITY INSERT ON

В принципе этому ничего не мешает, рабочая схема, самодельная MERGE-репликация. Но такое решение, конечно, кривоватое.
20 окт 15, 20:58    [18304713]     Ответить | Цитировать Сообщить модератору
 Re: Какие неприятности при регулярной коррекции автоинкрементного поля  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 31983
vladK
какие сюрпризы с таблицей могут меня ждать
SET IDENTITY_INSERT созможен только для одной таблицы в один момент, при сбое коннекта остаётся, во время его работы другие вставки в таблицу недопустимы.
В общем, не очень это хорошо.
20 окт 15, 21:02    [18304730]     Ответить | Цитировать Сообщить модератору
 Re: Какие неприятности при регулярной коррекции автоинкрементного поля  [new]
vladK
Member

Откуда: Харьков
Сообщений: 828
alexeyvg
Вопрос в том, можно ли сделать распределённую базу из двух нераспределённых, не меняя код, разделив инкрементные ИД по диапазонам, и делая синхронизацию вставками с включённым SET IDENTITY INSERT ON

Да, именно так. Спасибо что поняли.
Меня, правда больше волнует DBCC CHECKIDENT ('#t', RESEED, @LastLocID). Так как DBCC вроде как команды, к которым мы обращаемся разово, когда что то не так... А тут она прописана в регулярном процессе.
И второе, насколько вообще валидна ситуация с полем identity:
current identity value '6', current column value '101'


alexeyvg
SET IDENTITY_INSERT созможен только для одной таблицы в один момент, при сбое коннекта остаётся, во время его работы другие вставки в таблицу недопустимы.

Да, действительно. Это слабое место. Что как раз такое ожидал. Спасибо за подсказку.
Интересно что запуск пакетов SSIS у меня распараллелен, т.е. каждый пакет это одна таблица и пакеты несвязанных таблиц я запускаю параллельно, но на перекрытие SET IDENTITY_INSERT ON/OFF для разных таблиц я ещё ни разу не нарвался. (Сейчас работает синхронизация только во одну сторону LOC -->HUB)
21 окт 15, 11:29    [18306279]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: [1] 2   вперед  Ctrl      все
Все форумы / Microsoft SQL Server Ответить