क्या परिणाम अवरुद्ध कर रहा है "तालिका नाम से शीर्ष 1 * चुनें (नोलॉक)" परिणाम लौटने से?</p> <pre><code>select count(*) from adhoc..san_savedi with (nolock) </code></pre> <p>कि नहीं था ':

Question

मैं वर्तमान में निम्नलिखित बयान

select * into adhoc..san_savedi from dps_san..savedi_record 

यह एक दर्दनाक अधिक समय लग रहा है और मैं कितनी दूर देखना चाहते हैं के साथ यह इतना है कि मैं इस भाग चल रहा हूँ टी समय पर कुछ भी वापस नहीं लौटाता है, इसलिए मैंने यह किया:

select top 1 * from adhoc..san_savedi with (nolock) 

यहां तक ​​कि यह अनिश्चित काल तक चल रहा है। मैं समझ सकता हूं कि क्या लाखों रिकॉर्ड हैं कि गिनती (*) में काफी समय लग सकता है, लेकिन मुझे समझ में नहीं आ रहा है कि शीर्ष 1 रिकॉर्ड का चयन क्यों नहीं किया गया है, मैंने तुरंत निर्दिष्ट नोलॉक पर विचार किया है।

पूर्ण प्रकटीकरण के नाम पर, dps_san एक ऐसा दृश्य है जो लिंक किए गए सर्वर के माध्यम से एक ओडीबीसी कनेक्शन से खींचता है। मुझे नहीं लगता कि यह प्रभावित होगा कि मैं शीर्ष पंक्ति क्यों नहीं लौटा सकता हूं, लेकिन अगर मैं गलत हूं तो इसे वहां फेंक रहा हूं।

तो मैं जानना चाहता हूं कि उस कथन को चलने से क्या रोक रहा है?

संपादित करें:

मैं ऊपर उल्लेख किया है, हाँ dps_san..savedi_record एक दृश्य है। यहाँ यह क्या करता है:

select * from DPS_SAN..root.SAVEDI_RECORD 

यह एक उपनाम से ज्यादा कुछ नहीं है और करता है कोई समूहीकरण/छँटाई/आदि तो मुझे नहीं लगता कि समस्या यहाँ निहित है, लेकिन कृपया मुझे प्रबुद्ध अगर मैं उस के बारे में गलत हूँ।

Answer 1

SELECT प्रश्नों वास्तव में कोई ताले नहीं लेते, वे अभी भी एक SCH-S (स्कीमा स्थिरता) तालिका (and as it is a heap it will also take a hobt lock) पर ताला की जरूरत है।

SELECT से पहले इसके अतिरिक्त SQL सर्वर को भी कथन के लिए एक योजना संकलित करना शुरू कर सकता है, जिसके लिए इसे SCH-S तालिका पर लॉक करने की भी आवश्यकता होती है।

अपने लंबी चलने वाली लेन-देन के रूप में मेज SELECT ... INTO के माध्यम से इसे जब तक बयान पूरा करता है उस पर एक असंगत SCH-M ताला रखती है बनाता है।

आप जबकि अवरुद्ध की अवधि के दौरान, जबकि sys.dm_os_waiting_tasks में देख कर इसकी पुष्टि कर सकते हैं।

मैं एक कनेक्शन

BEGIN TRAN 

SELECT * 
INTO NewT 
FROM master..spt_values 

/*Remember to rollback/commit this later*/ 

में निम्नलिखित और फिर क्रियान्वित करने (या बस का अनुमान कार्य योजना लागू करके देखने की कोशिश कर)

SELECT * 
FROM NewT 
WITH (NOLOCK) 

एक दूसरे पढ़ने क्वेरी ब्लॉक किया गया था में

की कोशिश की।

SELECT wait_type, 
     resource_description 
FROM sys.dm_os_waiting_tasks 
WHERE session_id = <spid_of_waiting_task> 

शो इंतजार प्रकार वास्तव में SCH_S और अवरुद्ध संसाधन SCH-M

wait_type  resource_description 
---------------- ------------------------------------------------------------------------------------------------------------------------------- 
LCK_M_SCH_S  objectlock lockPartition=0 objid=461960722 subresource=FULL dbid=1 id=lock4a8a540 mode=Sch-M associatedObjectId=461960722 

Answer 2

यह बहुत अच्छा हो सकता है कि कोई ताले नहीं हैं ... यदि dps_san..savedi_record एक दृश्य है, तो इसे निष्पादित करने में लंबा समय लग सकता है, क्योंकि यह किसी इंडेक्स का उपयोग किये बिना टेबल तक पहुंच सकता है, या यह लाखों रिकॉर्ड, या जो भी कारण सॉर्ट हो सकता है। फिर आपकी क्वेरी, यहां तक ​​कि एक साधारण शीर्ष या गिनती, उतनी तेज होगी जितनी उस दृश्य को निष्पादित किया जा सकता है।

Answer 3

यहां पर विचार करने के लिए कुछ मुद्दे हैं। क्या dps_san..savedi_record एक दृश्य है? यदि ऐसा है, तो यह आपके डेटा को प्राप्त करने में वास्तव में बहुत लंबा समय ले सकता है। दूसरी बात यह है कि मैं सोच सकता हूं कि आप select into सिंटैक्स का उपयोग कर एक अस्थायी तालिका बनाने की कोशिश कर रहे हैं, जो एक बुरा विचार है। select * into ... वाक्यविन्यास चयन की अवधि के लिए tempdb लॉक करेगा।

यदि आप उस वाक्यविन्यास का उपयोग कर तालिका बना रहे हैं, तो एक कामकाज है। (ताला लगा tempdb के दंड के बिना

select * into ... from ... where 1=0 

यह पहली तालिका बनाएगा (जो तुरंत हो जाती है), क्योंकि तालिका अब मौजूद है जो insert into करने की अनुमति देता: सबसे पहले, अपने प्रारंभिक वक्तव्य के अंत में where 1=0 फेंक कर तालिका बनाने क्वेरी की अवधि के लिए)। NOLOCK साथ

Answer 4

session_id कि प्रदर्शन कर रहा है select into खोजें है:

SELECT r.session_id, r.blocking_session_id, r.wait_type, r.wait_time 
    FROM sys.dm_exec_requests AS r 
    CROSS APPLY sys.dm_exec_sql_text(r.plan_handle) AS t 
    WHERE t.[text] LIKE '%select%into%adhoc..san_savedi%'; 

यह देना चाहिए क्या आप दूसरे सत्र अगर पता चयन में अवरुद्ध कर रहा है या यदि इसमें एक प्रतीक्षा प्रकार है जो समस्या पैदा कर रहा है।

आप चयन करने की कोशिश कर रहे सत्र के लिए दूसरी विंडो में प्रक्रिया को दोहरा सकते हैं। मुझे संदेह है कि मार्टिन सही है और स्कीमा लॉक के बारे में मेरी पिछली टिप्पणी प्रासंगिक है।