SQL सर्वर 2016 में STRING_SPLIT ():फॉलो-अप #2

इस सप्ताह की शुरुआत में, मैंने STRING_SPLIT() के बारे में अपनी हाल की पोस्ट का अनुवर्ती पोस्ट किया था SQL सर्वर 2016 में, पोस्ट पर छोड़ी गई कई टिप्पणियों को संबोधित करना और/या सीधे मुझे भेजा गया:

• STRING_SPLIT() SQL सर्वर 2016 में :फ़ॉलो-अप #1

उस पोस्ट के ज्यादातर लिखे जाने के बाद, डौग एलनर का एक देर से आने वाला प्रश्न था:

स्टैक ओवरफ्लो पर @Nick_Craver के साथ हाल ही में ट्विटर एक्सचेंज के बाद, अब, टीवीपी का परीक्षण भविष्य की परियोजनाओं की मेरी सूची में पहले से ही था। उन्होंने कहा कि वे उत्साहित हैं कि STRING_SPLIT() अच्छा प्रदर्शन किया, क्योंकि वे तालिका-मूल्यवान पैरामीटर के माध्यम से ~7,000 मान भेजने के प्रदर्शन से नाखुश थे।

मेरे परीक्षण

इन परीक्षणों के लिए, मैंने पीसीआई स्टोरेज और 32 जीबी रैम के साथ 8-कोर विंडोज 10 वीएम पर SQL Server 2016 RC3 (13.0.1400.361) का उपयोग किया।

मैंने एक साधारण तालिका बनाई जो कि वे जो कर रहे थे उसकी नकल करते थे (3+ मिलियन पंक्ति पोस्ट तालिका से लगभग 10,000 मानों का चयन करना), लेकिन मेरे परीक्षणों के लिए, इसमें बहुत कम कॉलम और कम अनुक्रमणिकाएं हैं:

टेबल डीबीओ बनाएं। पोस्ट_रेगुलर (पोस्टआईडी इंट प्राथमिक कुंजी, हिटकाउंट इंट न्यूल डिफॉल्ट 0); INSERT dbo.Posts_Regular(PostID) सेलेक्ट टॉप (3000000) ROW_NUMBER() ओवर (s1.[object_id] द्वारा ऑर्डर) sys.all_objects AS s1 से क्रॉस जॉइन sys.all_objects AS s2;

मैंने एक इन-मेमोरी संस्करण भी बनाया, क्योंकि मैं उत्सुक था कि क्या कोई दृष्टिकोण वहां अलग तरीके से काम करेगा:

क्रिएट टेबल dbo.Posts_InMemory(PostID int PRIMARY KEY NONCLUSTERED HASH with (BUCKET_COUNT =4000000), HitCount int NOT NULL DEFAULT 0 with (MEMORY_OPTIMIZED =ON);

अब, मैं एक सी # ऐप बनाना चाहता था जो 10,000 अद्वितीय मानों में पारित होगा, या तो अल्पविराम से अलग स्ट्रिंग (स्ट्रिंगबिल्डर का उपयोग करके बनाया गया) या टीवीपी (डेटाटेबल से पारित) के रूप में। बिंदु एक मैच के आधार पर पंक्तियों के चयन को पुनः प्राप्त या अद्यतन करना होगा, या तो सूची को विभाजित करके उत्पादित तत्व या टीवीपी में एक स्पष्ट मूल्य के लिए। तो कोड प्रत्येक 300 वें मान को स्ट्रिंग या डेटाटेबल में जोड़ने के लिए लिखा गया था (सी # कोड नीचे परिशिष्ट में है)। मैंने मूल पोस्ट में बनाए गए कार्यों को लिया, उन्हें varchar(max) handle को संभालने के लिए बदल दिया , और फिर दो फ़ंक्शन जोड़े जिन्होंने एक TVP स्वीकार किया - उनमें से एक स्मृति-अनुकूलित। यहाँ तालिका प्रकार हैं (कार्य नीचे परिशिष्ट में हैं):

CREATE TYPE dbo.PostIDs_Regular AS TABLE(PostID int PRIMARY KEY);GO क्रिएट टाइप dbo.PostIDs_InMemory AS TABLE(PostID int NOT NULL PRIMARY KEY NONMOCLUSTERED HASH with WITH (BUCKET_COUNT =1000000); 

 मुझे स्ट्रिंग्स> 8K और> 8K एलिमेंट्स (मैंने इसे 1MM रो बनाया) को संभालने के लिए नंबर टेबल को बड़ा बनाना था। फिर मैंने सात संग्रहीत कार्यविधियाँ बनाईं:उनमें से पाँच एक varchar(max) . ले रही थीं और बेस टेबल को अपडेट करने के लिए फंक्शन आउटपुट के साथ जुड़ना, और फिर दो टीवीपी को स्वीकार करना और उसके खिलाफ सीधे जुड़ना। C# कोड इन सात प्रक्रियाओं में से प्रत्येक को 1,000 बार चुनने या अपडेट करने के लिए 10,000 पदों की सूची के साथ कॉल करता है। ये प्रक्रियाएं नीचे परिशिष्ट में भी हैं। तो संक्षेप में बताने के लिए, परीक्षण की जा रही विधियाँ हैं:
 
 
मूल (STRING_SPLIT() )
 
एक्सएमएल
 
सीएलआर
 
संख्या तालिका
 
JSON (स्पष्ट int के साथ) आउटपुट)
 
तालिका-मूल्यवान पैरामीटर
 
स्मृति-अनुकूलित तालिका-मूल्यवान पैरामीटर
 
 

 हम DataReader का उपयोग करके 10,000 मान, 1,000 बार पुनर्प्राप्त करने का परीक्षण करेंगे - लेकिन DataReader पर पुनरावृति नहीं कर रहे हैं, क्योंकि इससे परीक्षण में अधिक समय लगेगा, और C# एप्लिकेशन के लिए समान मात्रा में काम होगा, भले ही डेटाबेस कैसा भी हो सेट का उत्पादन किया। हम ExecuteNonQuery() का उपयोग करके 10,000 पंक्तियों, प्रत्येक को 1,000 बार अपडेट करने का परीक्षण भी करेंगे। . और हम पोस्ट टेबल के नियमित और मेमोरी-अनुकूलित दोनों संस्करणों के खिलाफ परीक्षण करेंगे, जिसे हम समानार्थी का उपयोग करके किसी भी फ़ंक्शन या प्रक्रिया को बदलने के बिना बहुत आसानी से स्विच कर सकते हैं:
 
समानार्थक डीबीओ बनाएं।डीबीओ के लिए पोस्ट।पोस्ट_रेगुलर; -- स्मृति-अनुकूलित संस्करण का परीक्षण करने के लिए:DROP SYNONYM dbo.Posts; SYNONYM dbo बनाएँ। dbo के लिए पोस्ट। पोस्ट_इनमेमरी; -- डिस्क-आधारित संस्करण का पुन:परीक्षण करने के लिए:DROP SYNONYM dbo.Posts;CREATE SYNONYM dbo.Posts FOR dbo.Posts_Regular;
 

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

 मैं कभी-कभी डेटा विज़ुअलाइज़ेशन के साथ संघर्ष करता हूं - मैंने वास्तव में एक चार्ट पर इन मीट्रिक का प्रतिनिधित्व करने का एक तरीका खोजने की कोशिश की, लेकिन मुझे लगता है कि प्रमुख लोगों को बाहर खड़ा करने के लिए अभी बहुत अधिक डेटा बिंदु थे। 
 

 आप इनमें से किसी को भी एक नए टैब/विंडो में बड़ा करने के लिए क्लिक कर सकते हैं, लेकिन अगर आपके पास एक छोटी सी खिड़की है तो भी मैंने रंग के उपयोग के माध्यम से विजेता को स्पष्ट करने की कोशिश की (और विजेता हर मामले में एक ही था)। और स्पष्ट होने के लिए, "औसत अवधि" से मेरा मतलब है कि आवेदन के लिए 1,000 संचालन के एक लूप को पूरा करने में लगने वाला औसत समय। 
 

  डिस्क-आधारित पोस्ट तालिका के विरुद्ध चयनों के लिए औसत अवधि (मिलीसेकंड) 
 

  औसत अवधि (मिलीसेकंड) डिस्क-आधारित पोस्ट तालिका के विरुद्ध अद्यतन के लिए 
 

 मेरे लिए यहां सबसे दिलचस्प बात यह है कि UPDATE के साथ सहायता करते समय स्मृति-अनुकूलित TVP ने कितना खराब प्रदर्शन किया . यह पता चला है कि डीएमएल शामिल होने पर समानांतर स्कैन वर्तमान में बहुत आक्रामक रूप से अवरुद्ध हैं; Microsoft ने इसे एक फीचर गैप के रूप में पहचाना है, और वे इसे जल्द ही संबोधित करने की उम्मीद कर रहे हैं। ध्यान दें कि समानांतर स्कैन वर्तमान में SELECT . के साथ संभव है लेकिन यह अभी डीएमएल के लिए अवरुद्ध है। (इसे SQL सर्वर 2014 में हल नहीं किया जाएगा, क्योंकि ये विशिष्ट समानांतर स्कैन ऑपरेशन किसी भी ऑपरेशन के लिए उपलब्ध नहीं हैं।) जब यह तय हो जाता है, या जब आपके टीवीपी छोटे होते हैं और/या समानांतरवाद वैसे भी फायदेमंद नहीं होता है, तो आपको देखना चाहिए कि स्मृति-अनुकूलित टीवीपी बेहतर प्रदर्शन करेंगे (अपेक्षाकृत बड़े टीवीपी के इस विशेष उपयोग के मामले में पैटर्न ठीक से काम नहीं करता है)। 
 

 इस विशिष्ट मामले के लिए, यहां SELECT . की योजनाएं दी गई हैं (जिसे मैं समानांतर जाने के लिए बाध्य कर सकता था) और अद्यतन (जो मैं नहीं कर सका):
 

 एक इन-मेमोरी TVP में डिस्क-आधारित तालिका में शामिल होने वाली एक चयन योजना में समानांतरवाद  
 

 डिस्क-आधारित तालिका को इन-मेमोरी से जोड़ने वाली अद्यतन योजना में कोई समानता नहीं है टीवीपी 
 
परिणाम - मेमोरी-अनुकूलित तालिकाएं
 

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

  स्मृति-अनुकूलित पोस्ट तालिका के विरुद्ध चयनों के लिए औसत अवधि (मिलीसेकंड) 
 

  स्मृति-अनुकूलित पोस्ट तालिका के विरुद्ध अद्यतन के लिए औसत अवधि (मिलीसेकंड) 
 

 
 
निष्कर्ष
 

 इस विशिष्ट परीक्षण के लिए, एक विशिष्ट डेटा आकार, वितरण और मापदंडों की संख्या के साथ, और मेरे विशेष हार्डवेयर पर, JSON एक सुसंगत विजेता था (हालांकि मामूली रूप से)। पिछली पोस्टों में कुछ अन्य परीक्षणों के लिए, हालांकि, अन्य दृष्टिकोणों ने बेहतर प्रदर्शन किया। आप क्या कर रहे हैं और आप इसे कहां कर रहे हैं, इसका एक उदाहरण विभिन्न तकनीकों की सापेक्ष दक्षता पर नाटकीय प्रभाव डाल सकता है, यहां इस संक्षिप्त श्रृंखला में जिन चीजों का परीक्षण किया गया है, उनके सारांश के साथ कि किस तकनीक को करना है उस स्थिति में उपयोग करें, और जिसे दूसरी या तीसरी पसंद के रूप में उपयोग करना है (उदाहरण के लिए, यदि आप कॉर्पोरेट नीति के कारण CLR लागू नहीं कर सकते हैं या क्योंकि आप Azure SQL डेटाबेस का उपयोग कर रहे हैं, या आप JSON या STRING_SPLIT () क्योंकि आप अभी तक SQL Server 2016 पर नहीं हैं)। ध्यान दें कि मैं वापस नहीं गया और वेरिएबल असाइनमेंट का पुन:परीक्षण नहीं किया और इसमें चयन करें टीवीपी का उपयोग करने वाली स्क्रिप्ट - ये परीक्षण यह मानकर स्थापित किए गए थे कि आपके पास पहले से ही सीएसवी प्रारूप में मौजूदा डेटा है जिसे पहले तोड़ा जाना होगा। आम तौर पर, यदि आप इससे बच सकते हैं, तो पहले अपने सेट को अल्पविराम से अलग किए गए स्ट्रिंग्स में न बदलें, IMHO। 
  <थ>पहली पसंद
लक्ष्य
 
दूसरा विकल्प (और तीसरा, जहां उपयुक्त हो)
 
 
सरल चर असाइनमेंट
 
STRING_SPLIT ()
 
CLR यदि <2016
XML यदि कोई CLR नहीं है और <2016
 
 
इसमें चुनें
 
सीएलआर
 
XML यदि कोई CLR नहीं है
 
 
चुनें (कोई स्पूल नहीं)
 
सीएलआर
 
नंबर तालिका यदि कोई CLR नहीं है
 
 
इनटू चुनें (कोई स्पूल + MAXDOP 1)
 
STRING_SPLIT ()
 
CLR यदि <2016
संख्या तालिका यदि कोई CLR नहीं है और <2016
 
 
बड़ी सूची में शामिल होने का चयन करें (डिस्क-आधारित)
 
JSON (int)
 
टीवीपी अगर <2016
 
 
बड़ी सूची में शामिल होने का चयन करें (स्मृति-अनुकूलित)
 
JSON (int)
 
टीवीपी अगर <2016
 
 
अपडेट करें बड़ी सूची में शामिल होना (डिस्क-आधारित)
 
JSON (int)
 
टीवीपी अगर <2016
 
 
अपडेट करें बड़ी सूची में शामिल होना (स्मृति-अनुकूलित)
 
JSON (int)
 
टीवीपी अगर <2016
 
 
 

 
 

 डौग के विशिष्ट प्रश्न के लिए:JSON, STRING_SPLIT() , और टीवीपी ने औसतन इन परीक्षणों में समान रूप से प्रदर्शन किया - इतना करीब कि टीवीपी स्पष्ट विकल्प हैं यदि आप SQL सर्वर 2016 पर नहीं हैं। यदि आपके पास अलग-अलग उपयोग के मामले हैं, तो ये परिणाम भिन्न हो सकते हैं। बहुत खूब . 
 

 जो हमें इस . की नैतिकता की ओर ले जाता है कहानी:मैं और अन्य किसी भी विशेषता या दृष्टिकोण के इर्द-गिर्द घूमते हुए बहुत विशिष्ट प्रदर्शन परीक्षण कर सकते हैं, और इस निष्कर्ष पर पहुँच सकते हैं कि कौन सा दृष्टिकोण सबसे तेज़ है। लेकिन इतने सारे चर हैं, मुझे यह कहने का आत्मविश्वास कभी नहीं होगा "यह दृष्टिकोण हमेशा हमेशा . है सबसे तेज़।" इस परिदृश्य में, मैंने अधिकांश योगदान करने वाले कारकों को नियंत्रित करने के लिए बहुत कठिन प्रयास किया, और जब JSON सभी चार मामलों में जीता, तो आप देख सकते हैं कि उन विभिन्न कारकों ने निष्पादन समय को कैसे प्रभावित किया (और कुछ दृष्टिकोणों के लिए बहुत अधिक)। तो यह अपने स्वयं के परीक्षण बनाने के लिए हमेशा इसके लायक है, और मुझे आशा है कि मैंने यह समझाने में मदद की है कि मैं उस तरह की चीज़ के बारे में कैसे जाता हूं।
 

 
 

 
 
परिशिष्ट A :कंसोल एप्लिकेशन कोड
 

 कृपया, इस कोड के बारे में कोई नाइट-पिकिंग नहीं; यह सचमुच एक बहुत ही सरल तरीके से इन संग्रहीत प्रक्रियाओं को चलाने के लिए एक बहुत ही सरल तरीके के रूप में एक साथ फेंक दिया गया था, सी # में इकट्ठे हुए डेटाटेबल्स और वास्तविक सूचियों के साथ, और प्रत्येक लूप को एक टेबल पर ले जाने के समय को लॉग करने के लिए (हैंडलिंग के साथ किसी भी एप्लिकेशन-संबंधित ओवरहेड को शामिल करना सुनिश्चित करने के लिए) या तो एक बड़ी स्ट्रिंग या संग्रह)। मैं एरर हैंडलिंग, लूप को अलग तरीके से जोड़ सकता था (उदाहरण के लिए काम की एक इकाई का पुन:उपयोग करने के बजाय लूप के अंदर सूचियां बनाना), और इसी तरह।
 
 सिस्टम का उपयोग करना; सिस्टम का उपयोग करना। नेमस्पेस स्प्लिटटेस्टिंग {कक्षा कार्यक्रम {स्थैतिक शून्य मुख्य (स्ट्रिंग [] तर्क) {स्ट्रिंग ऑपरेशन ="अपडेट"; अगर (तर्क [0]। ToString () =="-चयन करें") {ऑपरेशन ="चयन करें"; } वर सीएसवी =नया स्ट्रिंगबिल्डर (); डेटाटेबल तत्व =नया डेटाटेबल (); element.Columns.Add("value", typeof(int)); के लिए (int i =1; i <=10000; i++) {csv.Append((i*300).ToString ()); अगर (i <10000) {csv.Append(","); } तत्व। पंक्तियाँ। जोड़ें (i * 300); } स्ट्रिंग [] विधियाँ ={ "मूल", "CLR", "XML", "नंबर", "JSON", "TVP", "TVP_InMemory"}; (SqlConnection con =new SqlConnection ()) {con.ConnectionString =ConfigurationManager.ConnectionStrings ["प्राथमिक"] का उपयोग करके। ToString (); कॉन। ओपन (); एसक्लपैरामीटर पी; foreach (विधियों में स्ट्रिंग विधि) { SqlCommand cmd =नया SqlCommand ("dbo।" + ऑपरेशन + "पोस्ट_" + विधि, चुनाव); cmd.CommandType =CommandType.StoreedProcedure; अगर (विधि =="टीवीपी" || विधि =="TVP_InMemory") {cmd.Parameters.Add("@PostList", SqlDbType.Structured).Value =element; } और {cmd.Parameters.Add("@PostList", SqlDbType.VarChar, -1).Value =csv.ToString (); } वर टाइमर =System.Diagnostics.Stopwatch.StartNew (); के लिए (int x =1; x <=1000; x++) { अगर (ऑपरेशन =="अपडेट") {cmd.ExecuteNonQuery (); } और { SqlDataReader rdr =cmd.ExecuteReader (); आरडीआर। बंद करें (); } } टाइमर.स्टॉप (); लंबा यह_समय =टाइमर। विलुप्त मिलीसेकंड; // लॉग समय - लॉगिंग प्रक्रिया घड़ी का समय जोड़ती है और // मेमोरी / डिस्क-आधारित (समानार्थी के माध्यम से निर्धारित) रिकॉर्ड करती है SqlCommand लॉग =नया SqlCommand ("dbo.LogBatchTime", con); log.CommandType =CommandType.StoreedProcedure; log.Parameters.Add("@Operation", SqlDbType.VarChar, 32)। वैल्यू =ऑपरेशन; log.Parameters.Add("@Method", SqlDbType.VarChar, 32).Value =method; log.Parameters.Add("@Timing", SqlDbType.Int).Value =this_time; log.ExecuteNonQuery (); कंसोल। राइटलाइन (विधि + ":" + this_time.ToString ()); } } } }}
 

 नमूना उपयोग:
 SplitTesting.exe -चुनें
SplitTesting.exe -Update 

 
 
परिशिष्ट B :कार्य, प्रक्रिया और लॉगिंग तालिका
 

 यहां varchar(max) . को सपोर्ट करने के लिए एडिट किए गए फंक्शन दिए गए थे (सीएलआर फ़ंक्शन पहले ही स्वीकार कर लिया गया है nvarchar(max) और मैं अभी भी इसे बदलने की कोशिश करने के लिए अनिच्छुक था):
 
CREATE FUNCTION dbo.SplitStrings_Native(@List varchar(max), @Delimiter char(1))SCHEMABINDINGAS RETURN के साथ रिटर्न टेबल (चुनें [मान] STRING_SPLIT (@List, @Delimiter) से); जाओ FUNCTION dbo.SplitStrings बनाएं। ( @ लिस्ट वर्कर (अधिकतम), @ डिलीमीटर चार (1)) स्कीमबिंडिंगस रिटर्न के साथ रिटर्न टेबल (चुनें [मान] =वाई वैल्यू ('(./ टेक्स्ट ()) [1]', 'वर्कर (अधिकतम)') से (X =CONVERT(XML, '' + REPLACE(@List, @Delimiter, '') + '').query('.')) as a चुनें क्रॉस एप्लाई x.nodes('i') AS y(i));GO CREATE FUNCTION dbo.SplitStrings_Numbers(@List varchar(max), @Delimiter char(1))SCHEMABINDINGAS रिटर्न के साथ रिटर्न टेबल (चुनें [मान] =सबस्ट्रिंग (@सूची, संख्या, चरिन्देक्स(@Delimiter, @List + @Delimiter, संख्या) - संख्या) dbo.Numbers से जहां संख्या <=CONVERT(INT, LEN(@List)) और सबस्ट्रिंग(@Delimiter + @List, Number) , LEN(@Delimiter)) =@Delimiter );GO CREATE FUNCTION dbo.SplitStrings_JSON(@List varchar(max), @Delimiter char(1))SCH के साथ रिटर्न टेबल EMABINDINGAS रिटर्न (चुनें [मान] OPENJSON(CHAR(91) + @List + CHAR(93)) के साथ (मान int '$')); GO
 

 और संग्रहीत कार्यविधियाँ इस तरह दिखती थीं:
 
CREATE PROCEDURE dbo.UpdatePosts_Native @PostList varchar(max)ASBEGIN UPDATE p SET HitCount +=1 from dbo.Posts as p INNER JOIN dbo.SplitStrings_Native(@PostList, ',') एएस ऑन पी.पोस्टिड =ऑन पी। [मान];ENDGOCREATE PROCEDURE dbo.SelectPosts_Native @PostList varchar(max)ASBEGIN SELECT p.PostID, p.HitCount from dbo.Posts as p INNER JOIN dbo.SplitStrings_Native(@PostList, ',') AS =ON p.PostID s.[value];ENDGO-- 4 अन्य varchar(max)-आधारित विधियों के लिए दोहराएं प्रक्रिया बनाएं dbo.UpdatePosts_TVP @PostList dbo.PostIDs_Regular READONLY -- _Regular से _InMemoryASBEGIN SET NOCOUNT ON पर स्विच करें; अद्यतन पी सेट हिटकाउंट + =1 डीबीओ से। इनर के रूप में पोस्ट पी। पोस्टआईडी =एस। पोस्टआईडी पर @ पोस्टलिस्ट के रूप में शामिल हों; ENDGOCREATE PROCEDURE dbo.SelectPosts_TVP @PostList dbo.PostIDs_Regular READONLY पर स्विच करें - COUNT_ONRegular को SET_ONRegular पर स्विच करें; dbo.Posts से p.PostID, p.HitCount चुनें। इनर जॉइन @PostList AS s ON p.PostID =s.PostID;ENDGO-- इन-मेमोरी के लिए दोहराएं
 

 और अंत में, लॉगिंग टेबल और प्रक्रिया:
 
 टेबल डीबीओ बनाएं। स्प्लिटलॉग (लॉगिड इंट पहचान (1,1) प्राथमिक कुंजी, क्लॉकटाइम डेटाटाइम न्यूल डिफॉल्ट गेटडेट नहीं है (), ऑपरेटिंगटेबल नवरचर (513) न्यूल नहीं है, - पोस्ट_इनमेमरी या पोस्ट_रेगुलर ऑपरेशन वर्कर (32) न्यूल डिफॉल्ट नहीं है 'अपडेट', - या विधि varchar(32) NOT NULL DEFAULT 'Native', -- या TVP, JSON, आदि चुनें। @Method varchar(32), @Timing intASBEGIN SET NOCOUNT ON; INSERT dbo.SplitLog (ऑपरेटिंगटेबल, ऑपरेशन, मेथड, टाइमिंग) SELECT base_object_name, @Operation, @Method, @Timing FROM sys.synonyms WHERE name =N'Posts';ENDGO -- और ग्राफ़ जेनरेट करने के लिए क्वेरी:;साथ x AS (सेलेक्ट ऑपरेटिंगटेबल, ऑपरेशन, मेथड, टाइमिंग, रीसेंसी =ROW_NUMBER () ओवर (ऑपरेटिंगटेबल द्वारा पार्टिशन, ऑपरेशन, क्लॉकटाइम डीईएससी द्वारा मेथड ऑर्डर) डीबीओ से। स्प्लिटलॉग) सेलेक्ट ऑपरेटिंगटेबल, ऑपरेशन, मेथड, एवरेजड्यूरेशन =AVG (1.0 * टाइमिंग) FROM x WHERE Recency <=3GROUP by OperatingTable,Operation,Method;