Geekly articles weekly

MS SQL सर्वर की निगरानी के कुछ पहलू। ट्रेस झंडे स्थापित करने के लिए सिफारिशें

प्रस्तावना


अक्सर, MS SQL Server DBMS के उपयोगकर्ता, डेवलपर और व्यवस्थापक सामान्य रूप से डेटाबेस प्रदर्शन समस्याओं या DBMS का सामना करते हैं, इसलिए MS SQL सर्वर की निगरानी बहुत प्रासंगिक है।

यह लेख एमएस SQL ​​सर्वर डेटाबेस की निगरानी के लिए Zabbix का उपयोग करते हुए लेख का एक अतिरिक्त है और यह विशेष रूप से एमएस SQL ​​सर्वर की निगरानी के कुछ पहलुओं की जांच करेगा: विशेष रूप से यह निर्धारित करने के लिए कि संसाधन क्या गायब हैं, साथ ही ट्रेस झंडे स्थापित करने की सिफारिशें भी हैं।

निम्नलिखित स्क्रिप्ट को काम करने के लिए, आपको वांछित डेटाबेस में निम्न प्रकार से स्कीमा बनाना होगा:

एक inf स्कीमा बनाना
use <_>; go create schema inf;

रैम की कमी का पता लगाने के लिए विधि


RAM की कमी का पहला सूचक वह स्थिति है जब MS SQL सर्वर का एक उदाहरण इसके लिए आवंटित सभी RAM को खाता है।

ऐसा करने के लिए, निम्नलिखित inf.vRAM दृश्य बनाएं:

एक inf.vRAM व्यू बनाना
 CREATE view [inf].[vRAM] as select a.[TotalAvailOSRam_Mb] --       , a.[RAM_Avail_Percent] --     , a.[Server_physical_memory_Mb] --       , a.[SQL_server_committed_target_Mb] --     MS SQL Server   , a.[SQL_server_physical_memory_in_use_Mb] --    MS SQL Server       , a.[SQL_RAM_Avail_Percent] --    MS SQL Server      MS SQL Server , a.[StateMemorySQL] --    MS SQL Server , a.[SQL_RAM_Reserve_Percent] --    MS SQL Server     --     , (case when a.[RAM_Avail_Percent]<10 and a.[RAM_Avail_Percent]>5 and a.[TotalAvailOSRam_Mb]<8192 then 'Warning' when a.[RAM_Avail_Percent]<=5 and a.[TotalAvailOSRam_Mb]<2048 then 'Danger' else 'Normal' end) as [StateMemoryServer] from ( select cast(a0.available_physical_memory_kb/1024.0 as int) as TotalAvailOSRam_Mb , cast((a0.available_physical_memory_kb/casT(a0.total_physical_memory_kb as float))*100 as numeric(5,2)) as [RAM_Avail_Percent] , a0.system_low_memory_signal_state , ceiling(b.physical_memory_kb/1024.0) as [Server_physical_memory_Mb] , ceiling(b.committed_target_kb/1024.0) as [SQL_server_committed_target_Mb] , ceiling(a.physical_memory_in_use_kb/1024.0) as [SQL_server_physical_memory_in_use_Mb] , cast(((b.committed_target_kb-a.physical_memory_in_use_kb)/casT(b.committed_target_kb as float))*100 as numeric(5,2)) as [SQL_RAM_Avail_Percent] , cast((b.committed_target_kb/casT(a0.total_physical_memory_kb as float))*100 as numeric(5,2)) as [SQL_RAM_Reserve_Percent] , (case when (ceiling(b.committed_target_kb/1024.0)-1024)<ceiling(a.physical_memory_in_use_kb/1024.0) then 'Warning' else 'Normal' end) as [StateMemorySQL] from sys.dm_os_sys_memory as a0 cross join sys.dm_os_process_memory as a cross join sys.dm_os_sys_info as b cross join sys.dm_os_sys_memory as v ) as a;

तब आप यह निर्धारित कर सकते हैं कि MS SQL सर्वर का उदाहरण निम्नलिखित क्वेरी द्वारा उसे आवंटित सभी मेमोरी का उपभोग करता है:

 select SQL_server_physical_memory_in_use_Mb, SQL_server_committed_target_Mb from [inf].[vRAM];

यदि SQL_server_physical_memory_in_use_Mb संकेतक लगातार SQL_server_committed_target_Mb से कम नहीं है, तो आपको अपेक्षाओं के आंकड़ों की जांच करने की आवश्यकता है।

उम्मीद के आँकड़ों के माध्यम से रैम की कमी का निर्धारण करने के लिए, एक inf.vWaits दृश्य बनाएं:

एक inf.vWaits View बनाना
 CREATE view [inf].[vWaits] as WITH [Waits] AS (SELECT [wait_type], --   [wait_time_ms] / 1000.0 AS [WaitS],--      .    signal_wait_time_ms ([wait_time_ms] - [signal_wait_time_ms]) / 1000.0 AS [ResourceS],--        signal_wait_time_ms [signal_wait_time_ms] / 1000.0 AS [SignalS],--           [waiting_tasks_count] AS [WaitCount],--   .         100.0 * [wait_time_ms] / SUM ([wait_time_ms]) OVER() AS [Percentage], ROW_NUMBER() OVER(ORDER BY [wait_time_ms] DESC) AS [RowNum] FROM sys.dm_os_wait_stats WHERE [waiting_tasks_count]>0 and [wait_type] NOT IN ( N'BROKER_EVENTHANDLER', N'BROKER_RECEIVE_WAITFOR', N'BROKER_TASK_STOP', N'BROKER_TO_FLUSH', N'BROKER_TRANSMITTER', N'CHECKPOINT_QUEUE', N'CHKPT', N'CLR_AUTO_EVENT', N'CLR_MANUAL_EVENT', N'CLR_SEMAPHORE', N'DBMIRROR_DBM_EVENT', N'DBMIRROR_EVENTS_QUEUE', N'DBMIRROR_WORKER_QUEUE', N'DBMIRRORING_CMD', N'DIRTY_PAGE_POLL', N'DISPATCHER_QUEUE_SEMAPHORE', N'EXECSYNC', N'FSAGENT', N'FT_IFTS_SCHEDULER_IDLE_WAIT', N'FT_IFTSHC_MUTEX', N'HADR_CLUSAPI_CALL', N'HADR_FILESTREAM_IOMGR_IOCOMPLETION', N'HADR_LOGCAPTURE_WAIT', N'HADR_NOTIFICATION_DEQUEUE', N'HADR_TIMER_TASK', N'HADR_WORK_QUEUE', N'KSOURCE_WAKEUP', N'LAZYWRITER_SLEEP', N'LOGMGR_QUEUE', N'ONDEMAND_TASK_QUEUE', N'PWAIT_ALL_COMPONENTS_INITIALIZED', N'QDS_PERSIST_TASK_MAIN_LOOP_SLEEP', N'QDS_CLEANUP_STALE_QUERIES_TASK_MAIN_LOOP_SLEEP', N'REQUEST_FOR_DEADLOCK_SEARCH', N'RESOURCE_QUEUE', N'SERVER_IDLE_CHECK', N'SLEEP_BPOOL_FLUSH', N'SLEEP_DBSTARTUP', N'SLEEP_DCOMSTARTUP', N'SLEEP_MASTERDBREADY', N'SLEEP_MASTERMDREADY', N'SLEEP_MASTERUPGRADED', N'SLEEP_MSDBSTARTUP', N'SLEEP_SYSTEMTASK', N'SLEEP_TASK', N'SLEEP_TEMPDBSTARTUP', N'SNI_HTTP_ACCEPT', N'SP_SERVER_DIAGNOSTICS_SLEEP', N'SQLTRACE_BUFFER_FLUSH', N'SQLTRACE_INCREMENTAL_FLUSH_SLEEP', N'SQLTRACE_WAIT_ENTRIES', N'WAIT_FOR_RESULTS', N'WAITFOR', N'WAITFOR_TASKSHUTDOWN', N'WAIT_XTP_HOST_WAIT', N'WAIT_XTP_OFFLINE_CKPT_NEW_LOG', N'WAIT_XTP_CKPT_CLOSE', N'XE_DISPATCHER_JOIN', N'XE_DISPATCHER_WAIT', N'XE_TIMER_EVENT') ) , ress as ( SELECT [W1].[wait_type] AS [WaitType], CAST ([W1].[WaitS] AS DECIMAL (16, 2)) AS [Wait_S],--      .    signal_wait_time_ms CAST ([W1].[ResourceS] AS DECIMAL (16, 2)) AS [Resource_S],--        signal_wait_time_ms CAST ([W1].[SignalS] AS DECIMAL (16, 2)) AS [Signal_S],--           [W1].[WaitCount] AS [WaitCount],--   .         CAST ([W1].[Percentage] AS DECIMAL (5, 2)) AS [Percentage], CAST (([W1].[WaitS] / [W1].[WaitCount]) AS DECIMAL (16, 4)) AS [AvgWait_S], CAST (([W1].[ResourceS] / [W1].[WaitCount]) AS DECIMAL (16, 4)) AS [AvgRes_S], CAST (([W1].[SignalS] / [W1].[WaitCount]) AS DECIMAL (16, 4)) AS [AvgSig_S] FROM [Waits] AS [W1] INNER JOIN [Waits] AS [W2] ON [W2].[RowNum] <= [W1].[RowNum] GROUP BY [W1].[RowNum], [W1].[wait_type], [W1].[WaitS], [W1].[ResourceS], [W1].[SignalS], [W1].[WaitCount], [W1].[Percentage] HAVING SUM ([W2].[Percentage]) - [W1].[Percentage] < 95 -- percentage threshold ) SELECT [WaitType] ,MAX([Wait_S]) as [Wait_S] ,MAX([Resource_S]) as [Resource_S] ,MAX([Signal_S]) as [Signal_S] ,MAX([WaitCount]) as [WaitCount] ,MAX([Percentage]) as [Percentage] ,MAX([AvgWait_S]) as [AvgWait_S] ,MAX([AvgRes_S]) as [AvgRes_S] ,MAX([AvgSig_S]) as [AvgSig_S] FROM ress group by [WaitType];

इस स्थिति में, आप निम्न क्वेरी द्वारा रैम की कमी निर्धारित कर सकते हैं:

 SELECT [Percentage]      ,[AvgWait_S]  FROM [inf].[vWaits]  where [WaitType] in (    'PAGEIOLATCH_XX',    'RESOURCE_SEMAPHORE',    'RESOURCE_SEMAPHORE_QUERY_COMPILE'  );

यहां आपको प्रतिशतता और औसत लाभ के प्रदर्शन पर ध्यान देने की आवश्यकता है। यदि वे अपनी समग्रता में महत्वपूर्ण हैं, तो इस बात की बहुत अधिक संभावना है कि RAM MS SQL सर्वर के उदाहरण के लिए पर्याप्त नहीं है। प्रत्येक सिस्टम के लिए आवश्यक मान व्यक्तिगत रूप से निर्धारित किए जाते हैं। हालाँकि, आप निम्न मीट्रिक से शुरू कर सकते हैं: प्रतिशत> = 1 और औसत खाता = = 0.005।

मॉनिटरिंग सिस्टम के लिए संकेतक आउटपुट करने के लिए (उदाहरण के लिए, ज़ैबिक्स), आप निम्नलिखित दो प्रश्न बना सकते हैं:

  1. RAM अधिभोग के लिए अपेक्षाओं के प्रकार कितने प्रतिशत हैं (ऐसी सभी प्रकार की अपेक्षाओं के लिए योग):

     select coalesce(sum([Percentage]), 0.00) as [Percentage] from [inf].[vWaits] where [WaitType] in (    'PAGEIOLATCH_XX',    'RESOURCE_SEMAPHORE',    'RESOURCE_SEMAPHORE_QUERY_COMPILE'  );
  2. RAM कब्जे के लिए कितने मिलीसेकंड की अपेक्षाओं के प्रकार (ऐसी सभी प्रकार की अपेक्षाओं के लिए सभी औसत देरी का अधिकतम मूल्य):

     select coalesce(max([AvgWait_S])*1000, 0.00) as [AvgWait_MS] from [inf].[vWaits] where [WaitType] in (    'PAGEIOLATCH_XX',    'RESOURCE_SEMAPHORE',    'RESOURCE_SEMAPHORE_QUERY_COMPILE'  );

इन दो संकेतकों के लिए प्राप्त मूल्यों की गतिशीलता के आधार पर, हम यह निष्कर्ष निकाल सकते हैं कि क्या एमएस SQL ​​सर्वर के उदाहरण के लिए पर्याप्त रैम है।

सीपीयू अधिभार का पता लगाने की विधि


CPU समय की कमी की पहचान करने के लिए, बस sysinos_os_schedulers सिस्टम दृश्य का उपयोग करें। यहाँ, यदि runnable_tasks_count इंडिकेटर लगातार 1 से अधिक है, तो एक उच्च संभावना है कि कोर की संख्या एमएस SQL ​​सर्वर के उदाहरण के लिए पर्याप्त नहीं है।

मॉनिटरिंग सिस्टम में संकेतक प्रदर्शित करने के लिए (उदाहरण के लिए, ज़ैबिक्स), आप निम्नलिखित क्वेरी बना सकते हैं:

 select max([runnable_tasks_count]) as [runnable_tasks_count] from sys.dm_os_schedulers where scheduler_id<255;

इस सूचक के लिए प्राप्त मूल्यों की गतिशीलता के आधार पर, हम यह निष्कर्ष निकाल सकते हैं कि क्या एमएस SQL ​​सर्वर के उदाहरण के लिए पर्याप्त प्रोसेसर समय (सीपीयू कोर की संख्या) है।
हालांकि, इस तथ्य को याद रखना महत्वपूर्ण है कि अनुरोध स्वयं एक साथ कई थ्रेड्स का अनुरोध कर सकते हैं। और कभी-कभी ऑप्टिमाइज़र अनुरोध की जटिलता का सही आकलन नहीं कर पाता है। फिर अनुरोध को कई थ्रेड आवंटित किए जा सकते हैं जो एक निश्चित समय पर एक साथ संसाधित नहीं किए जा सकते हैं। और यह प्रोसेसर समय की कमी से जुड़े एक प्रकार की प्रतीक्षा का भी कारण बनता है, और शेड्यूलर के लिए कतार की वृद्धि जो विशिष्ट सीपीयू कोर का उपयोग करते हैं, अर्थात, runnable_tasks_count संकेतक ऐसी परिस्थितियों में बढ़ेगा।

इस मामले में, सीपीयू कोर की संख्या बढ़ाने से पहले, आपको एमएस SQL ​​सर्वर के उदाहरण के समानांतरवाद गुणों को सही ढंग से कॉन्फ़िगर करना होगा, और 2016 संस्करण से, आवश्यक डेटाबेस के समानांतरवाद गुणों को सही ढंग से कॉन्फ़िगर करना होगा:





यहाँ यह निम्नलिखित मापदंडों पर ध्यान देने योग्य है:

  1. समानांतरवाद की अधिकतम डिग्री प्रत्येक अनुरोध के लिए आवंटित किए जा सकने वाले धागों की अधिकतम संख्या निर्धारित करती है (केवल ऑपरेटिंग सिस्टम और MS SQL सर्वर संस्करण द्वारा डिफ़ॉल्ट 0 प्रतिबंध है)
  2. समानांतरता के लिए लागत सीमा - समानता की अनुमानित लागत (डिफ़ॉल्ट 5 है)
  3. अधिकतम DOP- थ्रेड्स की अधिकतम संख्या सेट करता है, जिन्हें डेटाबेस स्तर पर प्रत्येक क्वेरी के लिए आवंटित किया जा सकता है (लेकिन "अधिकतम डिग्री ऑफ़ पैरेललिज्म" प्रॉपर्टी के मूल्य से अधिक नहीं) (डिफ़ॉल्ट 0-प्रतिबंध केवल ऑपरेटिंग सिस्टम और MS SQL सर्वर संस्करण द्वारा है, संपूर्ण MS SQL सर्वर आवृत्ति की "समानांतरता की अधिकतम डिग्री" संपत्ति पर प्रतिबंध के साथ-साथ)

सभी मामलों के लिए समान रूप से अच्छा नुस्खा देना असंभव है, अर्थात, आपको कठिन अनुरोधों का विश्लेषण करने की आवश्यकता है।

अपने स्वयं के अनुभव से, मैं समानतावाद गुणों को कॉन्फ़िगर करने के लिए OLTP सिस्टम के लिए क्रियाओं के निम्नलिखित एल्गोरिदम की सिफारिश करता हूं:

  1. समांतरवाद के अधिकतम डिग्री के पूरे उदाहरण के स्तर को सेट करके पहला प्रतिबंध संगामिति
  2. सबसे कठिन अनुरोधों का विश्लेषण करें और उनके लिए थ्रेड्स की इष्टतम संख्या चुनें
  3. आइटम 2 से प्राप्त थ्रेड्स की चयनित अधिकतम संख्या के लिए समानांतर डिग्री की अधिकतम डिग्री सेट करें, और विशिष्ट डेटाबेस के लिए प्रत्येक डेटाबेस के लिए आइटम 2 से प्राप्त मैक्स डीओपी मूल्य निर्धारित करें।
  4. सबसे कठिन अनुरोधों का विश्लेषण करें और मल्टीथ्रेडिंग के नकारात्मक प्रभाव की पहचान करें। यदि यह है, तो समानांतरता के लिए लागत सीमा को बढ़ाएं।
    1 सी, माइक्रोसॉफ्ट सीआरएम और माइक्रोसॉफ्ट एनएवी जैसी प्रणालियों के लिए, ज्यादातर मामलों में, मल्टीथ्रेडिंग का निषेध उपयुक्त है।

इसके अलावा, यदि मानक संस्करण स्थापित है, तो ज्यादातर मामलों में मल्टीथ्रेडिंग का निषेध इस तथ्य को देखते हुए उपयुक्त है कि यह संस्करण सीपीयू कोर की संख्या द्वारा सीमित है।

OLAP सिस्टम के लिए, ऊपर वर्णित एल्गोरिथ्म उपयुक्त नहीं है।

अपने स्वयं के अनुभव से, मैं समानतावाद गुण स्थापित करने के लिए OLAP- सिस्टम के लिए क्रियाओं के निम्नलिखित एल्गोरिदम की सिफारिश करता हूं:

  1. सबसे कठिन अनुरोधों का विश्लेषण करें और उनके लिए थ्रेड्स की इष्टतम संख्या चुनें
  2. आइटम 1 से प्राप्त धागों की चयनित इष्टतम संख्या के लिए समानांतर डिग्री की अधिकतम डिग्री सेट करें, और विशिष्ट डेटाबेस के लिए भी प्रत्येक डेटाबेस के लिए आइटम 1 से प्राप्त मैक्स डीओपी मूल्य निर्धारित करें।
  3. सबसे कठिन अनुरोधों का विश्लेषण करें और संगामिति सीमा के नकारात्मक प्रभाव की पहचान करें। यदि यह है, तो या तो समानांतर मूल्य के लिए लागत थ्रेसहोल्ड को कम करें, या इस एल्गोरिथ्म के 1-2 चरणों को दोहराएं

यही है, ओएलटीपी सिस्टम के लिए हम सिंगल-थ्रेडेड से मल्टीथ्रेडिंग तक जाते हैं, और ओएलएपी-सिस्टम के लिए, इसके विपरीत, हम मल्टीथ्रेडिंग से सिंगल-थ्रेडेड पर जाते हैं। इस प्रकार, किसी विशिष्ट डेटाबेस और संपूर्ण MS SQL सर्वर आवृत्ति दोनों के लिए इष्टतम संगामिति सेटिंग्स का चयन करना संभव है।
यह समझना भी महत्वपूर्ण है कि एमएस SQL ​​सर्वर के प्रदर्शन की निगरानी के परिणामों के आधार पर समय के साथ संगामिति गुण सेटिंग्स को बदलने की आवश्यकता है।

ट्रेस झंडे स्थापित करने के लिए सिफारिशें


अपने स्वयं के अनुभव और अपने सहकर्मियों के अनुभव से, मैं इष्टतम प्रदर्शन के लिए 2008-2016 संस्करणों के लिए एमएस SQL ​​सर्वर सेवा के स्टार्टअप स्तर पर निम्नलिखित ट्रेस झंडे स्थापित करने की सलाह देता हूं:

  1. 610 - अनुक्रमित तालिकाओं में आवेषण के लॉगिंग को कम करना। यह अनुक्रमणिका में परिवर्तन के लिए WRITELOG की लगातार लंबी अपेक्षाओं के साथ बड़ी संख्या में रिकॉर्ड और कई लेनदेन के साथ तालिकाओं में आवेषण में मदद कर सकता है
  2. 1117 - यदि किसी फ़ाइल समूह में कोई फ़ाइल स्वचालित विकास सीमा से मिलती है, तो फ़ाइल समूह में सभी फ़ाइलें विस्तारित हो जाती हैं
  3. 1118 - सभी वस्तुओं को अलग-अलग एक्सटेंशंस (मिश्रित एक्सटेंट पर प्रतिबंध) में स्थित होने के लिए मजबूर किया जाता है, जो एसजीएएम पेज को स्कैन करने की आवश्यकता को कम करता है, जो मिश्रित एक्सटेंशन्स को ट्रैक करने के लिए उपयोग किया जाता है।
  4. 1224 - ताले की संख्या के आधार पर लॉक एस्केलेशन को अक्षम करता है। अत्यधिक मेमोरी उपयोग में लॉक एस्केलेशन शामिल हो सकता है।
  5. 2371 - डायनेमिक ऑटोमैटिक स्टैटिस्टिक्स अपडेट के लिए थ्रेशोल्ड को फिक्स्ड ऑटोमैटिक स्टैट्स अपडेट के लिए थ्रेसहोल्ड में बदलाव करता है। बड़ी तालिकाओं के लिए क्वेरी योजनाओं को अपडेट करना महत्वपूर्ण है जहां गलत तरीके से रिकॉर्ड की संख्या का निर्धारण गलत निष्पादन योजनाओं की ओर जाता है
  6. 3226 - त्रुटि लॉग में सफल बैकअप संदेश दबाता है
  7. 4199 - संचयी अद्यतन और SQL सर्वर सर्विस पैक में जारी क्वेरी ऑप्टिमाइज़र में परिवर्तन शामिल हैं
  8. 6532-6534 - स्थानिक डेटा प्रकारों के लिए बेहतर क्वेरी प्रदर्शन शामिल है
  9. 8048 - NUMA ने मेमोरी ऑब्जेक्ट को सीपीयू में विभाजित किया
  10. 8780 - किसी अनुरोध को निर्धारित करने के लिए अतिरिक्त समय आवंटन को सक्षम करता है। इस ध्वज के बिना कुछ अनुरोधों को अस्वीकार कर दिया जा सकता है क्योंकि उनके पास अनुरोध योजना नहीं है (बहुत दुर्लभ त्रुटि)
  11. 9389 - बैच मोड ऑपरेटरों के लिए अस्थायी रूप से उपलब्ध कराया गया एक अतिरिक्त डायनेमिक मेमोरी बफ़र शामिल है, जो अतिरिक्त मेमोरी का अनुरोध करने के लिए बैच मोड ऑपरेटर को सक्षम करता है और यदि अतिरिक्त मेमोरी उपलब्ध है तो डेटा को टेम्पर्डब पर स्थानांतरित करने से बचें।

2016 के संस्करण से पहले, ट्रेस फ्लैग 2301 को शामिल करना उपयोगी है, जिसमें विस्तारित निर्णय समर्थन का अनुकूलन शामिल है और जिससे अधिक क्वेरी प्लान चुनने में मदद मिलती है। हालांकि, 2016 के संस्करण से शुरू होकर, यह अक्सर एक लंबे समय के समग्र क्वेरी निष्पादन समय में नकारात्मक प्रभाव डालता है।

इसके अलावा, उन प्रणालियों के लिए जिनमें बहुत सारे इंडेक्स हैं (उदाहरण के लिए, 1 सी डेटाबेस), मेरा सुझाव है कि आप ट्रेस फ्लैग 2330 को सक्षम करें, जो इंडेक्स के उपयोग पर संग्रह को निष्क्रिय करता है, जिसका आमतौर पर सिस्टम पर सकारात्मक प्रभाव पड़ता है।

ट्रेस झंडे के बारे में अधिक जानें यहां ।

उपरोक्त लिंक का उपयोग करना, MS SQL सर्वर के संस्करणों और असेंबली पर विचार करना भी महत्वपूर्ण है, क्योंकि नए संस्करणों के लिए, कुछ ट्रेस झंडे डिफ़ॉल्ट रूप से सक्षम हैं या कोई प्रभाव नहीं है। उदाहरण के लिए, 2017 संस्करण में, केवल निम्नलिखित 5 ट्रेस झंडे सेट करना प्रासंगिक है: 1224, 3226, 6534, 8780 और 9389।

आप क्रमशः DBCC TRACEON और DBCC TRACEOFF आदेशों का उपयोग करके ट्रेस ध्वज को सक्षम या अक्षम कर सकते हैं। अधिक जानकारी के लिए यहां देखें।

आप DBCC TRACESTATUS कमांड का उपयोग करके ट्रेस झंडे की स्थिति प्राप्त कर सकते हैं: और ।

एमएस SQL ​​सर्वर सेवा के ऑटोरन में शामिल किए जाने वाले ट्रेस झंडे के लिए, आपको SQL सर्वर कॉन्फ़िगरेशन प्रबंधक में जाने की आवश्यकता है और इन ट्रेस झंडों को -T के माध्यम से सेवा गुणों में जोड़ना होगा:



परिणाम


इस लेख में, एमएस SQL ​​सर्वर मॉनिटरिंग के कुछ पहलुओं की जांच की गई, जिसकी मदद से आप रैम और सीपीयू खाली समय की कमी, साथ ही साथ कई अन्य कम स्पष्ट समस्याओं की पहचान कर सकते हैं। सबसे अधिक इस्तेमाल किए जाने वाले ट्रेस झंडे पर विचार किया गया था।

सूत्रों का कहना है


» एसक्यूएल सर्वर स्टैंडबाय सांख्यिकी
» SQL सर्वर के आकांक्षा आँकड़े या कृपया मुझे बताएं कि यह कहाँ दर्द होता है
» सिस्टम दृश्य sysinos_os_schedulers
» MS SQL सर्वर डेटाबेस को ट्रैक करने के लिए Zabbix का उपयोग करना
» SQL जीवन शैली
» ट्रेस झंडे
» Sql.ru

Source: https://habr.com/ru/post/hi448044/

More articles:


All Articles