Innym rozwiązaniem jest użycie wielu schematów i granie w zamianę. Preferuję tę metodę tylko dlatego, że robiłem tę sztuczkę w pracy, a komunikat ostrzegawczy o zmianie nazwy obiektu (której nie można pominąć) wypełniał moje logi historii. Zasadniczo potrzebujesz dwóch dodatkowych schematów (jeden do tymczasowego przechowywania kopii tabeli, a drugi do przechowywania kopii z pamięci podręcznej).
CREATE SCHEMA cache AUTHORIZATION dbo;
CREATE SCHEMA hold AUTHORIZATION dbo;
Teraz utwórz imitację tabeli w schemacie pamięci podręcznej:
SELECT * INTO cache.table FROM dbo.table WHERE 1 = 0;
-- then create any indexes etc.
Teraz, gdy nadejdzie czas na odświeżenie danych:
-- 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;
Teoretycznie możesz przenieść ostatni przelew z transakcji, ponieważ użytkownicy mogli zacznij wysyłać zapytania do nowej kopii dbo.table po drugim transferze, ale jak powiedziałem, jest to prawie natychmiastowe, więc byłbym zaskoczony, jeśli zauważysz jakąkolwiek różnicę we współbieżności.
Możesz także opcjonalnie obciąć cache.table znowu tutaj, ale zawsze utrzymywałem to wypełnione, aby móc porównać zmiany danych lub rozwiązać problemy, jeśli coś poszło nie tak. W zależności od tego, ile czasu zajmie krok 1, wykonanie transferów w odwrotnej kolejności może być szybsze niż ponowne wypełnienie od zera.
Podobnie jak zmiana nazwy, możesz uzyskać dziwne rzeczy z tego procesu, takie jak gubienie statystyk, gdy poruszają się z rzeczywistą tabelą, nie trzymają się nazwy. I podobnie jak zmiana nazwy, będziesz chciał to przetestować i możesz chcieć pobawić się poziomami izolacji, np. RCSI dostępu do tabeli raportowania.
