DB2 v10 zos: определение свободных значений индекса

Question

В моей организации сотни таблиц DB2, каждая из которых имеет случайно генерируемый уникальный целочисленный индекс. Случайные значения генерируются либо с помощью мэйнфреймов COBOL CICS, либо из распределенных приложений Java. Обычный подход - случайное генерирование целочисленного значения (используются только положительные значения), затем попытка вставить строку данных, повторить попытку, когда значение повторяющегося индекса уже сохранено. Я хотел бы улучшить производительность этого подхода, и я подумываю о попытке определить целые значения, которые не были созданы и сохранены для каждой таблицы, это будет означать, что нам не нужно повторять попытку. Мы бы знали, что наша вставка будет работать. Есть ли функция db2, которая может возвращать неиспользуемые значения индекса?

Answer 1

Короткий ответ: нет.

Несколько более длинный ответ заключается в том, чтобы указать, что, если бы такая функция существовала, в вашем случае на первой вставке в одну из ваших таблиц размер возвращаемого результата будет равен 2,147,483,647 (позитивные) целые числа. При каждом 4 байтах это будет 8 589 934 588 байт.

Учитывая ограничения существующей системы, то, что вы делаете, вероятно, является лучшим, что можно сделать. Если выполнение повторной попытки неприемлемо, я боюсь, что перестройка вашей ключевой схемы - это следующий шаг.

Я думаю, что это вопрос, который нужно задать: Является ли эта схема использования случайных чисел для уникальных ключей, вызывающих проблемы с производительностью? Поскольку таблицы заполняют ключевое пространство, вы увидите все больше повторений, но у вас относительно большое ключевое пространство. Если вы видите большое количество повторений, возможно, ваши случайные числа менее случайны, чем вам хотелось бы.

Answer 2

просто мысль, но вы можете использовать одну последовательность для группы таблиц. Таким образом, значение будет по-прежнему произвольным (потому что вы не знаете, к какой из следующих таблиц вы вставляете), но на основе определенной последовательности, означающей, что большую часть времени вы не будете повторять попытку, потому что число продолжает расти. тот же Sequance может зацикливаться после нескольких hunderd миллионов вставок и начать «заполнять пробелы».

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