Solusi lain adalah dengan menggunakan beberapa skema dan memainkan switch-a-roo. Saya hanya lebih suka metode ini karena saya biasa melakukan trik ini dalam pekerjaan, dan pesan peringatan tentang mengganti nama objek (yang tidak dapat ditekan) mengisi log riwayat saya. Pada dasarnya Anda memerlukan dua skema tambahan (satu untuk menyimpan salinan tabel sementara, dan satu lagi untuk menyimpan salinan yang di-cache).
CREATE SCHEMA cache AUTHORIZATION dbo;
CREATE SCHEMA hold AUTHORIZATION dbo;
Sekarang, buat tiruan tabel dalam skema cache:
SELECT * INTO cache.table FROM dbo.table WHERE 1 = 0;
-- then create any indexes etc.
Sekarang saatnya untuk menyegarkan data:
-- 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;
Secara teoritis, Anda dapat memindahkan transfer terakhir dari transaksi, karena pengguna bisa mulai menanyakan salinan baru dbo.table setelah transfer kedua, tetapi seperti yang saya katakan, ini hampir seketika jadi saya akan terkejut jika Anda melihat perbedaan dalam konkurensi.
Anda juga dapat secara opsional memotong cache.table lagi di sini, tetapi saya selalu membuatnya tetap terisi sehingga saya dapat membandingkan perubahan data atau memecahkan masalah jika ada yang tidak beres. Bergantung pada berapa lama -- langkah 1 diperlukan, mungkin lebih cepat melakukan transfer secara terbalik daripada mengisi ulang dari awal.
Seperti mengubah nama, Anda bisa mendapatkan hal-hal miring dari proses ini, seperti statistik hilang saat mereka bergerak dengan tabel yang sebenarnya, mereka tidak menempel dengan nama. Dan seperti mengganti nama, Anda ingin menguji ini dan Anda mungkin ingin bermain-main dengan level isolasi, mis. RCSI untuk mengakses tabel pelaporan.
