Друго решение е да използвате множество схеми и да играете switch-a-roo. Предпочитам този метод само защото използвах този трик в една работа и предупредителното съобщение за преименуване на обект (което не може да бъде потиснато) запълваше регистрационните ми файлове с история. По принцип ви трябват две допълнителни схеми (една за временно съхраняване на копие на таблицата и една за съхраняване на кешираното копие).
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 след второто прехвърляне, но както казах, това е почти мигновено, така че ще се изненадам, ако видите някаква разлика в паралелността.
Можете също така по желание да съкратите cache.table отново тук, но винаги го поддържах попълнен, за да мога да сравня промените в данните или да отстраня неизправности, ако нещо се обърка. В зависимост от това колко време отнема -- стъпка 1, може да е по-бързо да извършите прехвърлянията в обратен ред, отколкото да попълните отново от нулата.
Подобно на преименуването, можете да получите странни неща от този процес, като статистиката да се загуби, докато се движи с действителната таблица, те не се придържат към името. И като преименуване, ще искате да тествате това и може да искате да си поиграете с нивата на изолация, напр. RCSI за достъп до отчетната таблица.
