Một giải pháp khác là sử dụng nhiều lược đồ và chơi switch-a-roo. Tôi chỉ thích phương pháp này hơn vì tôi đã từng thực hiện thủ thuật này trong một công việc và thông báo cảnh báo về việc đổi tên một đối tượng (không thể bị chặn) đang lấp đầy nhật ký lịch sử của tôi. Về cơ bản, bạn cần hai lược đồ bổ sung (một để giữ bản sao của bảng tạm thời và một để giữ bản sao đã lưu trong bộ nhớ cache).
CREATE SCHEMA cache AUTHORIZATION dbo;
CREATE SCHEMA hold AUTHORIZATION dbo;
Bây giờ, hãy tạo một bảng bắt chước trong lược đồ bộ nhớ cache:
SELECT * INTO cache.table FROM dbo.table WHERE 1 = 0;
-- then create any indexes etc.
Bây giờ, khi cần làm mới dữ liệu:
-- 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;
Về mặt lý thuyết, bạn có thể chuyển lần chuyển cuối cùng ra khỏi giao dịch, bởi vì người dùng có thể bắt đầu truy vấn bản sao mới của dbo.table sau lần chuyển thứ hai, nhưng như tôi đã nói, điều này gần như diễn ra ngay lập tức nên tôi sẽ rất ngạc nhiên nếu bạn thấy bất kỳ sự khác biệt nào về đồng thời.
Bạn cũng có thể tùy chọn cắt bớt cache.table một lần nữa ở đây, nhưng tôi luôn giữ nó được điền để tôi có thể so sánh các thay đổi dữ liệu hoặc khắc phục sự cố nếu có sự cố. Tùy thuộc vào thời gian thực hiện - bước 1, có thể nhanh hơn để thực hiện chuyển ngược lại so với điền lại từ đầu.
Giống như đổi tên, bạn có thể nhận được những điều khó khăn từ quá trình này, chẳng hạn như số liệu thống kê bị mất khi chúng di chuyển với bảng thực tế, chúng không dính với tên. Và giống như đổi tên, bạn sẽ muốn kiểm tra điều này và bạn có thể muốn thử nghiệm với các cấp độ cô lập, ví dụ:RCSI để truy cập bảng báo cáo.
