Dalším řešením je použít více schémat a hrát switch-a-roo. Tuto metodu preferuji pouze proto, že jsem tento trik prováděl v práci a varovné hlášení o přejmenování objektu (které nelze potlačit) zaplňovalo mé protokoly historie. V zásadě potřebujete dvě další schémata (jedno pro dočasné uložení kopie tabulky a druhé pro uložení kopie uložené v mezipaměti).
CREATE SCHEMA cache AUTHORIZATION dbo;
CREATE SCHEMA hold AUTHORIZATION dbo;
Nyní vytvořte napodobeninu tabulky ve schématu mezipaměti:
SELECT * INTO cache.table FROM dbo.table WHERE 1 = 0;
-- then create any indexes etc.
Nyní, když přijde čas na obnovení dat:
-- 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;
Teoreticky byste mohli přesunout poslední převod z transakce, protože uživatelé mohli začněte se dotazovat na novou kopii dbo.table po druhém přenosu, ale jak jsem řekl, je to téměř okamžité, takže by mě překvapilo, kdyby jste viděli nějaký rozdíl v souběžnosti.
Můžete také volitelně zkrátit cache.table znovu zde, ale vždy jsem to nechal vyplněné, abych mohl porovnávat změny dat nebo odstraňovat problémy, pokud se něco pokazilo. V závislosti na tom, jak dlouho -- krok 1 trvá, může být rychlejší provést převody obráceně, než je znovu naplnit od začátku.
Stejně jako přejmenování můžete z tohoto procesu získat podivné věci, jako je ztráta statistik, když se pohybují se skutečnou tabulkou, nedrží se jména. A stejně jako přejmenování, budete to chtít vyzkoušet a možná si budete chtít pohrát s úrovněmi izolace, např. RCSI pro přístup k tabulce hlášení.