Столбец идентификации Teradata и повторяющаяся ошибка уникального простого ключа в dbname.tablename

Я создал таблицу, используя приведенное ниже определение для столбца идентификации Teradata:

      ID INTEGER GENERATED BY DEFAULT AS IDENTITY
           (START WITH 1 
            INCREMENT BY 1 
            MINVALUE 0 
            MAXVALUE 100000000 
            NO CYCLE),
----
      UNIQUE PRIMARY INDEX ( ID )

Уже несколько месяцев столбец ID работает исправно, автоматически генерируя уникальное значение для столбца. Однако за последний месяц ELMAH периодически сообщал о следующем исключении из нашего приложения .NET 4.0 ASP.NET:

Teradata.Client.Provider.TdException: [Teradata Database] [2801] Duplicate unique prime key error in DATABASENAME.TABLENAME.

Я смог воспроизвести его, открыв SQL Assistant и вставив кучу записей в таблицу с необработанным SQL. Как и ожидалось, в большинстве случаев он вставлялся успешно, но в других случаях выдавал указанное выше исключение.

Похоже, эта ошибка возникает из-за того, что Teradata пытается сгенерировать значение для этого столбца, которое было создано ранее.

Кто-нибудь знает, как докопаться до сути происходящего? По крайней мере, я хотел бы немного глубже отладить проблему.


identity teradata unique
person oscilatingcretin    schedule 30.07.2012    source источник

Ответы (1)


arrow_upward
0
arrow_downward

Я бы предложил изменить определение вашего столбца идентификаторов на GENERATED ALWAYS, чтобы приложение или процесс ETL не предоставляли значение, которое можно было бы использовать. На самом деле, Teradata рекомендует, чтобы при использовании столбца IDENTITY как части UPI он определялся как GENERATED ALWAYS ... NO CYCLE.

ИЗМЕНИТЬ:

Если ваши бизнес-требования таковы, что вы должны иметь возможность предоставить значение, я бы также рассмотрел возможность использования домена, который находится за пределами диапазона значений, которые вы установили для столбца IDENTITY. Вы можете использовать отрицательный домен или диапазон, который на порядок больше, чем в столбце IDENTITY. Личное предпочтение было бы использовать отрицательный домен.

person Rob Paller    schedule 30.07.2012
comment
Разве generated always не мешает вам вставить собственное значение в столбец идентификаторов? По причинам, которые я не буду объяснять для простоты, мне нужна возможность указать мое собственное значение для этого поля при вставке новой записи, тем самым переопределяя поведение Teradata по присвоению значения самому себе. Когда я хочу, чтобы база данных сгенерировала его для меня, я просто не включаю имя поля в оператор вставки. - person oscilatingcretin; 31.07.2012
comment
Когда вы столкнулись с этой ошибкой, вы предоставили значения в своем необработанном SQL для UPI или полагались на Teradata для создания значений идентификатора для вас? - person Rob Paller; 31.07.2012
comment
В этом случае я полагался на Teradata для генерации значений. Это означает, что я бы использовал insert into mydb.employee (name, email) values ('bob', '[email protected]') вместо insert into mydb.employee (id, name, email) values (100, 'bob', '[email protected]'). Все это работает примерно с февраля этого года. Теперь мы начинаем получать это в нашей среде разработки. Я хочу исправить это до того, как это начнет происходить в производстве, потому что это было бы плохо. Когда вы говорите отрицательный домен, вы имеете в виду использование отрицательных чисел для первичного ключа? Значит, чей-то ID может быть -100? - person oscilatingcretin; 31.07.2012
comment
Столбец ID, заполняемый столбцом IDENTITY, представляет собой суррогатный ключ, который используется в качестве первичного индекса. Отрицательный домен гарантирует, что значения, предоставленные человеком, никогда не будут конфликтовать с доменом, который вы выделили для Teradata для использования при создании значения IDENTITY. Первичный ключ — это логическая конструкция, обеспечивающая уникальность Сотрудника. Первичный индекс (уникальный или нет) в Teradata — это физическая конструкция, определяющая распределение данных в AMPS. - person Rob Paller; 31.07.2012
comment
Можете ли вы создать копию этой таблицы со столбцом IDENTITY, определенным как GENERATED ALWAYS... NO CYCLE, и попытаться воспроизвести проблему в процессе разработки? - person Rob Paller; 31.07.2012
comment
Я мог бы, но я думаю, что пришло время сократить свои потери на этом и попробовать новый метод. Поскольку он работал нормально в течение почти шести месяцев, невозможно сказать, сколько раз мне пришлось бы вставлять записи, прежде чем я смог бы воспроизвести его, и то, что он не воспроизвел его после вставки 1000 записей, все еще не означает, что этого не произошло бы, если бы Я позволил ему вставить еще одну запись. Я открыл новый вопрос, с которым, возможно, вы могли бы помочь: - person oscilatingcretin; 31.07.2012
comment
stackoverflow.com/questions/11744846/ - person oscilatingcretin; 31.07.2012
comment
Смотрите мой ответ на ваш новый вопрос. :) - person Rob Paller; 31.07.2012