एक अन्य समाधान एकाधिक स्कीमा का उपयोग करना और स्विच-ए-रू खेलना है। मैं केवल इस विधि को पसंद करता हूं क्योंकि मैं इस चाल को नौकरी में करता था, और किसी वस्तु का नाम बदलने के बारे में चेतावनी संदेश (जिसे दबाया नहीं जा सकता) मेरे इतिहास लॉग भर रहा था। मूल रूप से आपको दो अतिरिक्त स्कीमा की आवश्यकता होती है (एक अस्थायी रूप से तालिका की प्रतिलिपि रखने के लिए, और एक कैश की गई प्रतिलिपि रखने के लिए)।
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।
