У меня есть очень большой набор данных (~3 миллиона записей), который должен быть объединен с обновлениями и новыми записями в ежедневном расписании. У меня есть хранимая процедура, которая на самом деле разбивается, официальный набор документов в 1 000 записей разделяет на блоки и использует MERGE
команда с временными таблицами в попытке постараться не блокировать живую таблицу, в то время как данные обновляют. Проблема состоит в том, что это точно не помогает. Таблица все еще "запирается" и наш веб-сайт, который использует данные, получает тайм-ауты при попытке получить доступ к данным. Я даже попытался разделить его на 100 рекордных блоков и даже попробовал a WAITFOR DELAY '000:00:5'
видеть, помогло ли это приостановиться между слиянием блоков. Это все еще довольно вяло.
Я ищу любые предложения, лучшие практики или примеры того, как объединить большие наборы данных, не блокируя таблицы.
Спасибо
Измените свой интерфейс на использование NOLOCK или READ UNCOMMITTED, когда выбирает .
Вы не можете NOLOCK MERGE, INSERT или UPDATE, так как записи должны быть заблокированы для выполнения обновления. Однако вы можете БЛОКИРОВАТЬ ВЫБОРЫ.
Обратите внимание, что следует использовать это с осторожностью. Если грязное чтение в порядке, продолжайте.Однако, если для чтения требуются обновленные данные, вам нужно пойти другим путем и точно выяснить, почему объединение записей 3M вызывает проблему.
Я готов поспорить, что большую часть времени тратится на чтение данных с диска во время выполнения команды слияния и / или на работу в ситуациях с нехваткой памяти. Возможно, вам лучше просто вставить больше оперативной памяти в свой сервер базы данных.
Идеальным было бы иметь достаточно оперативной памяти для загрузки всей базы данных в память по мере необходимости. Например, если у вас база данных 4 ГБ, убедитесь, что у вас есть 8 ГБ ОЗУ ... на сервере x64, конечно.