Самый эффективный способ перемещения строк таблицы из одной таблицы в другую

Question

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

Я думаю, что у меня есть отдельная таблица, в которой мой процесс вставляет/обновляет и когда-то завершает работу, нужен способ подтолкнуть эти изменения к моей рабочей таблице производства.

любая помощь была бы замечательной!

Answer 1

Другим решением является использование нескольких схем и играть переключатель-а-сл. Я предпочитаю только этот метод, потому что я использовал этот трюк в задании, и предупреждающее сообщение о переименовании объекта (которое не может быть подавлено) заполняло мои журналы истории. В основном вам нужны две дополнительные схемы (одна для временного хранения копии таблицы и одна для хранения кешированной копии).

CREATE SCHEMA cache AUTHORIZATION dbo; 
CREATE SCHEMA hold AUTHORIZATION dbo; 

Теперь создайте подражание таблицы в схеме кэша:

SELECT * INTO cache.table FROM dbo.table WHERE 1 = 0; 
-- then create any indexes etc. 

Теперь, когда приходит время, чтобы обновить данные:

-- step 1: 
TRUNCATE TABLE cache.table; 
-- (if you need to maintain FKs you may need to delete) 
INSERT INTO cache.table SELECT ... 

-- step 2: 
-- this transaction will be almost instantaneous, 
-- since it is a metadata operation only: 

BEGIN TRANSACTION; 
    ALTER SCHEMA hold TRANSFER dbo.table; 
    ALTER SCHEMA dbo TRANSFER cache.table; 
    ALTER SCHEMA cache TRANSFER hold.table; 
COMMIT TRANSACTION; 

Теоретически, вы можете переместить последняя передача из транзакции, поскольку пользователи могут начать запрашивать новую копию dbo.table после второй передачи, но, как я уже сказал, это almos t мгновенно, поэтому я был бы удивлен, если вы увидите разницу в параллелизме.

Здесь вы также можете усекать cache.table, но я всегда его заполнял, поэтому я мог сравнивать данные об изменениях или устранять неполадки, если что-то пошло не так. В зависимости от того, как долго - шаг 1, может быть быстрее выполнить переводы в обратном порядке, чем повторное заполнение с нуля.

Как и в случае переименования, вы можете получить неуловимые вещи из этого процесса, такие как потеря статистики при перемещении с фактической таблицей, они не придерживаются имени. И, подобно переименованию, вы захотите проверить это, и вы можете играть с уровнями изоляции, например. RCSI для доступа к таблице отчетов.

Answer 2

Одним из решений было бы сделать это с указанной вами временной таблицей, а затем просто изменить ее имя на имя производственной таблицы (но сначала переименуйте производственную таблицу во что-то другое). После этого вы можете просто отказаться от прежнего рабочего стола. Конечно, вы должны делать все это внутри транзакции.

Таким образом, было бы:

-- Fill tmpTable 
-- 

-- Do renaming 
begin tran t1; 
execute sp_rename 'productionTable', 'productionTableBackup'; 
execute sp_rename 'tmpTable', 'productionTable'; 
commit tran t1;