न्यूनतम डाउनटाइम के साथ बड़ी मात्रा में डेटा को फिर से आयात करने का सबसे अच्छा तरीका है

Question

मुझे सप्ताह में एक बार (केवल तीन int / bigint cols) आईपी लुकअप (केवल पढ़ने के लिए संदर्भ) युक्त लगभग 500,000 रिकॉर्ड आयात करने की आवश्यकता है।

मैं वास्तव में मौजूदा तालिका के साथ डेटा को मर्ज करने के बारे में चिंता नहीं करना चाहता, मैं पुराने और रीमपोर्ट को खाली करना पसंद करूंगा।

आदर्श रूप से डेटा पर चल रही क्वेरीज़ चलती रहेंगी (हमें इनमें से बहुत कुछ नहीं मिलता है और आयात के घटने के दौरान थोड़ा धीमा चलना उनके लिए स्वीकार्य है, लेकिन इसे 24/7 करने की आवश्यकता है, इसलिए इसे चलाएं " घंटे के बाहर "एक विकल्प नहीं है)।

अब तक की कोशिश की बातें

SSIS: मैंने एक SSIS पैकेज बनाया है जो तालिका और आयात को छोटा करता है - इसे चलाने में लगभग 30 सेकंड लगते हैं (वास्तव में बहुत लंबा)।

टेंप टेबल: एक टेम्प टेबल में आयात, ट्रंकिंग और कॉपी करना भी लगभग 30 सेकंड लगते हैं।

BCP: बल्क इंपोर्ट भी बहुत धीमा है (किसी कारण से यह SSIS की तुलना में धीमा है (यहां तक ​​कि इसे बनाए रखने के लिए कोई संकेत नहीं है) - मैं अनुमान लगा रहा हूं कि यह char-> int / bigint लेनदेन के साथ कुछ करना है: /

मिरर टेबल? इसलिए, इस समय, मैं एक दृश्य के माध्यम से तालिका को पढ़ने के बारे में सोच रहा हूं, दर्पण तालिका में डेटा आयात कर रहा हूं, और इस तालिका को इंगित करने के लिए दृश्य को बदल रहा हूं ... ऐसा लगता है कि यह त्वरित होगा, लेकिन यह छोटा लगता है मेरे लिए थोड़ा हैकी।

ऐसा लगता है कि यह एक आम समस्या होनी चाहिए, लेकिन मैं अनुशंसित प्रथाओं को नहीं पा सकता हूं - किसी भी विचार की सबसे अधिक सराहना की जाएगी!

धन्यवाद

Answer 1

एक समाधान जो मैंने अतीत में इस्तेमाल किया है (और इससे पहले और यहाँ StackOverflow पर सिफारिश की है) दो अतिरिक्त स्कीमा बनाना है:

CREATE SCHEMA shadow AUTHORIZATION dbo;
CREATE SCHEMA cache  AUTHORIZATION dbo;

अब cacheस्कीमा में अपनी तालिका की नकल बनाएं :

CREATE TABLE cache.IPLookup(...columns...);

अब जब आप अपना स्विच ऑपरेशन कर रहे हैं:

TRUNCATE TABLE cache.IPLookup;
BULK INSERT cache.IPLookup FROM ...;

-- the nice thing about the above is that it doesn't really
-- matter if it takes one minute or ten - you're not messing
-- with a table that anyone is using, so you aren't going to
-- interfere with active users.


-- this is a metadata operation so extremely fast - it will wait
-- for existing locks to be released, but won't block new locks
-- for very long at all:

BEGIN TRANSACTION;
  ALTER SCHEMA shadow TRANSFER    dbo.IPLookup;
  ALTER SCHEMA dbo    TRANSFER  cache.IPLookup;
COMMIT TRANSACTION;


-- now let's move the shadow table back over to
-- the cache schema so it's ready for next load:

ALTER SCHEMA cache TRANSFER shadow.IPLookup;
TRUNCATE TABLE cache.IPLookup; 

-- truncate is optional - I usually keep the data
-- around for debugging, but that's probably not
-- necessary in this case.

यदि आपके पास विदेशी कुंजियाँ और अन्य निर्भरताएँ हैं (क्योंकि आपको उन्हें छोड़ना होगा और उन्हें फिर से बनाना होगा), तो यह अधिक बोझिल होगा, और निश्चित रूप से यह आँकड़ों को पूरी तरह से अमान्य कर देता है और यह, बदले में, योजनाओं को प्रभावित कर सकता है, लेकिन अगर सबसे महत्वपूर्ण बात यह है कि आपके उपयोगकर्ताओं के सामने न्यूनतम रुकावट के साथ सटीक डेटा मिल रहा है, यह विचार करने के लिए एक दृष्टिकोण हो सकता है।

Comments

धन्यवाद, एक और दिलचस्प विकल्प - मुझे लगता है कि अंतिम दो कथन काफी सही नहीं हैं, कैश पर छाया को स्थानांतरित करना चाहिए, और कैश को कम करना चाहिए। मुझे आश्चर्य है कि अगर समानार्थी शब्द भी इस्तेमाल किया जा सकता है?

— मार्क

तुम सही हो, मैं उन लोगों को मिलाया। मुझे यकीन नहीं है कि समानार्थी शब्द कैसे बेहतर होंगे, मुझे लगता है कि यह एक दृष्टिकोण भी है - एक ऐसा दृष्टिकोण है जो एक समानार्थी को इंगित करता है, और दूसरे संस्करण को पॉप्युलेट करने पर अंतर्निहित लेन-देन को एक लेनदेन में बदल देता है। व्यक्तिगत रूप से मुझे यह थोड़ा बेहतर लगता है - जब आप dbo.IPLookup को क्वेरी कर रहे होते हैं, तो आप जानते हैं कि "वर्तमान" तालिका बिना देखे और पर्यायवाची बने रहती है।

— हारून बर्ट्रेंड

: FYI करें मैं इस सप्ताह और अधिक विस्तार में इस बारे में भी ब्लॉग sqlperformance.com/2012/08/t-sql-queries/...

— हारून बर्ट्रेंड