پرو هوسٽر > بلاگ > انتظاميه > MS SQL سرور مانيٽرنگ جا ڪجھ حصا. ٽريس پرچم سيٽنگ لاء هدايتون

MS SQL سرور مانيٽرنگ جا ڪجھ حصا. ٽريس پرچم سيٽنگ لاء هدايتون

اڳوڻي

گهڻو ڪري، MS SQL Server DBMS جا استعمال ڪندڙ، ڊولپرز ۽ منتظمين مجموعي طور تي ڊيٽابيس يا DBMS جي ڪارڪردگي جي مسئلن کي منهن ڏين ٿا، تنهنڪري MS SQL سرور مانيٽرنگ تمام لاڳاپيل آهي.
هي مضمون مضمون ۾ اضافو آهي MS SQL سرور ڊيٽابيس کي مانيٽر ڪرڻ لاء زيبڪس استعمال ڪندي ۽ اهو MS SQL سرور جي نگراني جي ڪجهه حصن کي ڍڪيندو، خاص طور تي: ڪيئن جلدي طئي ڪيو وڃي ته ڪهڙا وسيلا غائب آهن، ۽ انهي سان گڏ ٽريس جھنڊن کي ترتيب ڏيڻ لاء سفارشون.
ھيٺ ڏنل اسڪرپٽ ڪم ڪرڻ لاء، توھان کي ھيٺ ڏنل ڊيٽابيس ۾ ھڪڙي انف اسڪيما ٺاھڻ جي ضرورت آھي:
هڪ inf اسڪيما ٺاهڻ

use <имя_БД>;
go
create schema inf;

رام جي کوٽ کي ڳولڻ جو طريقو

رام جي گھٽتائي جو پهريون اشارو اهو معاملو آهي جڏهن MS SQL سرور جو هڪ مثال ان کي مختص ڪيل سڀني رام کي کائي ٿو.
هن کي ڪرڻ لاء، اسان 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 کان وڌيڪ يا برابر آهي، پوء انتظار جي انگن اکرن کي جانچڻ گهرجي.
انتظار جي انگن اکرن ذريعي RAM جي کوٽ کي طئي ڪرڻ لاء، اچو ته ٺاهيو 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'
  );

هتي توهان کي ڌيان ڏيڻ جي ضرورت آهي اشارن تي فيصد ۽ AvgWait_S. جيڪڏهن اهي انهن جي مجموعي ۾ اهم آهن، پوء اتي هڪ تمام وڏو امڪان آهي ته MS SQL سرور مثال لاء ڪافي رام نه آهي. اهم قدر هر سسٽم لاء انفرادي طور تي مقرر ڪيا ويا آهن. بهرحال، توھان ھيٺين سان شروع ڪري سگھو ٿا: فيصد>=1 ۽ AvgWait_S>=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'
  );

انهن ٻن اشارن لاء حاصل ڪيل قدرن جي متحرڪ جي بنياد تي، اسان اهو نتيجو ڪري سگهون ٿا ته ڇا MS SQL سرور جي مثال لاء ڪافي رام آهي.

سي پي يو اوورلوڊ ڳولڻ جو طريقو

پروسيسر جي وقت جي کوٽ کي سڃاڻڻ لاء، اهو استعمال ڪرڻ ڪافي آهي sys.dm_os_schedulers سسٽم ڏيک. هتي، جيڪڏهن runnable_tasks_count مسلسل 1 کان وڌيڪ آهي، ته پوء اتي هڪ وڏو امڪان آهي ته ڪور جو تعداد ڪافي نه آهي MS SQL سرور مثال لاء.
مانيٽرنگ سسٽم ڏانهن اشارو ڪڍڻ لاءِ (مثال طور، Zabbix)، توھان ھيٺ ڏنل سوال ٺاھي سگھو ٿا:

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

هن اشاري لاءِ حاصل ڪيل قدرن جي متحرڪ جي بنياد تي، اسان اهو نتيجو ڪري سگهون ٿا ته ڇا ڪافي پروسيسر وقت آهي (سي پي يو ڪور جو تعداد) مثال طور MS SQL سرور لاءِ.
بهرحال، اها حقيقت ذهن ۾ رکڻ ضروري آهي ته درخواستون پاڻ هڪ ئي وقت ڪيترن ئي موضوعن جي درخواست ڪري سگهن ٿيون. ۽ ڪڏهن ڪڏهن اصلاح ڪندڙ پاڻ سوال جي پيچيدگي جو صحيح اندازو نٿو لڳائي سگهي. پوءِ درخواست تمام گھڻا سلسلا مختص ڪيا ويندا جيڪي ڏنل وقت تي ساڳئي وقت تي عمل نه ٿي ڪري سگھجن. ۽ اهو پڻ پروسيسر جي وقت جي گهٽتائي سان لاڳاپيل هڪ قسم جو انتظار ڪري ٿو، ۽ شيڊولرز جي قطار جي ترقي جيڪي مخصوص سي پي يو ڪور استعمال ڪن ٿا، يعني runnable_tasks_count اشارو اهڙين حالتن ۾ وڌندو.
انهي صورت ۾، سي پي يو ڪور جي تعداد کي وڌائڻ کان اڳ، ضروري آهي ته MS SQL سرور مثال جي متوازي خاصيتن کي صحيح طور تي ترتيب ڏيو، ۽ 2016 ورزن کان، صحيح طور تي ترتيب ڏيو متوازي ملڪيت جي گهربل ڊيٽابيس جي:
MS SQL سرور مانيٽرنگ جا ڪجھ حصا. ٽريس پرچم سيٽنگ لاء هدايتون

MS SQL سرور مانيٽرنگ جا ڪجھ حصا. ٽريس پرچم سيٽنگ لاء هدايتون
هتي توهان کي هيٺين پيراگراف تي ڌيان ڏيڻ گهرجي:

  1. متوازي جي وڌ ۾ وڌ درجي - وڌ ۾ وڌ تعداد کي سيٽ ڪري ٿو جيڪي هر درخواست لاء مختص ڪري سگھجن ٿيون (ڊفالٽ 0 آهي - صرف آپريٽنگ سسٽم طرفان محدود آهي ۽ MS SQL سرور جي ايڊيشن)
  2. متوازي جي قيمت جي حد - متوازي جي تخميني قيمت (ڊفالٽ 5 آهي)
  3. وڌ ۾ وڌ DOP - سلسلن جو وڌ ۾ وڌ تعداد مقرر ڪري ٿو جيڪي ڊيٽابيس جي سطح تي هر سوال لاءِ مختص ڪري سگھجن ٿيون (پر "Max Degree of Parallelism" ملڪيت جي قيمت کان وڌيڪ نه) (ڊفالٽ 0 آهي - صرف آپريٽنگ سسٽم طرفان محدود آهي ۽ MS SQL سرور جو ايڊيشن، گڏوگڏ MS SQL سرور جي پوري مثال جي "Max Degree of Parallelism" ملڪيت تي پابندي)

هتي اهو ناممڪن آهي ته سڀني ڪيسن لاء هڪ جيتري سٺي ترڪيب ڏيو، يعني توهان کي ڳري سوالن جو تجزيو ڪرڻ جي ضرورت آهي.
منهنجي پنهنجي تجربي مان، مان سفارش ڪريان ٿو هيٺين الگورتھم عملن جي OLTP سسٽم لاءِ متوازي ملڪيت قائم ڪرڻ لاءِ:

  1. پهرين متوازيت کي غير فعال ڪريو مثال جي حد تائين متوازي جي وڌ ۾ وڌ درجي کي 1 تي سيٽ ڪندي
  2. سڀ کان وڏي درخواستن جو تجزيو ڪريو ۽ انھن لاءِ موضوعن جو بھترين تعداد چونڊيو
  3. متوازي جي وڌ ۾ وڌ درجي کي سيٽ ڪريو ٿريڊز جي چونڊيل انگن اکرن لاءِ جيڪو قدم 2 مان حاصل ڪيو ويو آهي، ۽ مخصوص ڊيٽابيس لاءِ هر ڊيٽابيس لاءِ اسٽيپ 2 مان حاصل ڪيل وڌ کان وڌ DOP قيمت مقرر ڪريو.
  4. تمام گهڻي درخواستن جو تجزيو ڪريو ۽ ملٽي ٿريڊنگ جي ناڪاري اثر جي نشاندهي ڪريو. جيڪڏهن اهو آهي، پوء متوازي لاء قيمت جي حد وڌايو.
    سسٽم لاءِ جهڙوڪ 1C، Microsoft CRM ۽ Microsoft NAV، اڪثر ڪيسن ۾، ملٽي ٿريڊنگ کي منع ڪرڻ مناسب آهي.

انهي سان گڏ، جيڪڏهن ڪو معياري ايڊيشن آهي، ته پوء اڪثر ڪيسن ۾ ملٽي ٿريڊنگ جي ممانعت مناسب آهي ڇاڪاڻ ته هن ايڊيشن ۾ سي پي يو ڪور جي تعداد ۾ محدود آهي.
OLAP سسٽم لاءِ، مٿي بيان ڪيل الگورتھم مناسب نه آھي.
منهنجي پنهنجي تجربي مان، مان سفارش ڪريان ٿو هيٺين الگورتھم عملن جي OLAP سسٽم لاءِ متوازي ملڪيت قائم ڪرڻ لاءِ:

  1. سڀ کان وڏي درخواستن جو تجزيو ڪريو ۽ انھن لاءِ موضوعن جو بھترين تعداد چونڊيو
  2. متوازي جي وڌ ۾ وڌ درجي کي سيٽ ڪريو ٿريڊز جي چونڊيل انگن اکرن لاءِ جيڪو قدم 1 مان حاصل ڪيو ويو آهي، ۽ مخصوص ڊيٽابيس لاءِ هر ڊيٽابيس لاءِ اسٽيپ 1 مان حاصل ڪيل وڌ کان وڌ DOP قيمت مقرر ڪريو.
  3. تمام گھڻا سوالن جو تجزيو ڪريو ۽ سنگت کي محدود ڪرڻ جي ناڪاري اثر کي سڃاڻو. جيڪڏهن اهو آهي، ته پوءِ يا ته قيمت جي حد کي گهٽ ڪريو Parallelism Value لاءِ، يا ورجايو 1-2 هن الگورتھم جا مرحلا

اھو آھي، OLTP سسٽم لاءِ اسين سنگل ٿريڊنگ کان ملٽي ٿريڊنگ ڏانھن وڃون ٿا، ۽ OLAP-سسٽم لاءِ، ان جي برعڪس، اسين ملٽي ٿريڊنگ کان سنگل ٿريڊنگ ڏانھن وڃون ٿا. اهڙيء طرح، توهان هڪ مخصوص ڊيٽابيس ۽ MS SQL سرور جي پوري مثال لاء بهترين متوازي سيٽنگون چونڊي سگهو ٿا.
اهو سمجهڻ پڻ ضروري آهي ته متوازي خاصيتن جي سيٽنگن کي وقت سان تبديل ٿيڻ جي ضرورت آهي، MS SQL سرور جي ڪارڪردگي جي نگراني جي نتيجن جي بنياد تي.

ٽريس پرچم سيٽنگ لاء هدايتون

منهنجي پنهنجي تجربي ۽ منهنجي ساٿين جي تجربي مان، بهتر ڪارڪردگيءَ لاءِ، مان سفارش ڪريان ٿو هيٺ ڏنل ٽريس جھنڊن کي ترتيب ڏيو MS SQL سرور سروس جي رن ليول تي ورجن 2008-2016 لاءِ:

  1. 610 - انڊيڪس ٿيل جدولن ۾ داخل ٿيڻ جي گھٽتائي. گھڻن رڪارڊن ۽ ڪيترن ئي ٽرانزيڪشن سان جدولن ۾ داخل ڪرڻ ۾ مدد ڪري سگھن ٿا، بار بار WRITELOG انڊيڪس ۾ تبديلين جو انتظار ڪري ٿو
  2. 1117 - جيڪڏهن فائلگروپ ۾ ڪا فائل آٽو گروٿ حد جي گهرج پوري ڪري ٿي، فائلگروپ ۾ سڀ فائلون وڌنديون
  3. 1118 - سڀني شين کي مختلف حدن ۾ واقع ٿيڻ تي مجبور ڪري ٿو (مخلوط حدن جي ممانعت)، جيڪا SGAM صفحي کي اسڪين ڪرڻ جي ضرورت کي گھٽائي ٿي، جيڪو مخلوط حدن کي ٽريڪ ڪرڻ لاء استعمال ڪيو ويندو آهي.
  4. 1224 - لاڪ جي تعداد جي بنياد تي تالا وڌائڻ کي بند ڪري ٿو. جڏهن ته، گهڻو ڪري ياداشت جي استعمال کي بند ڪري سگهي ٿو واڌارو
  5. 2371 - تبديل ٿيل خودڪار شمارياتي تازه ڪاري حد کي متحرڪ خودڪار شماريات تازه ڪاري حد تائين. وڏي جدولن لاءِ سوالن جي منصوبن کي اپڊيٽ ڪرڻ لاءِ اهم، جتي رڪارڊ جي غلط ڳڻپ جي نتيجي ۾ غلط عمل جي منصوبن جي نتيجي ۾
  6. 3226 - غلطي لاگ ۾ بيڪ اپ ڪامياب پيغامن کي دٻايو
  7. 4199 - CUs ۽ SQL Server Service Packs ۾ جاري ڪيل سوال آپٽمائزر ۾ تبديليون شامل آھن
  8. 6532-6534 - مقامي ڊيٽا جي قسمن تي سوالن جي عملن لاءِ ڪارڪردگي بهتري شامل آھي
  9. 8048 - NUMA ورهاڱي ٿيل ميموري شين کي سي پي يو ورهاڱي وارن شين ۾ تبديل ڪري ٿو
  10. 8780 - سوال جي منصوبابندي لاءِ اضافي وقت مختص ڪرڻ کي قابل بڻائي ٿو. ڪجھ درخواستون ھن جھنڊي کان سواءِ رد ڪري سگھجن ٿيون ڇاڪاڻ ته انھن وٽ ڪو سوال پلان نه آھي (تمام نادر بگ)
  11. 8780 - 9389 - بيچ موڊ بيانن لاءِ اضافي متحرڪ گرانٽ ميموري بفر کي فعال ڪري ٿو، جيڪو بيچ موڊ آپريٽر کي اضافي ميموري جي درخواست ڪرڻ جي اجازت ڏئي ٿو ۽ ڊيٽا کي tempdb ڏانهن منتقل ڪرڻ کان پاسو ڪري ٿو جيڪڏهن اضافي ميموري موجود آهي.

2016 کان اڳ پڻ، اهو ڪارائتو آهي ته ٽريس پرچم 2301 کي فعال ڪيو وڃي، جيڪو بهتر ڪيل فيصلي جي حمايت جي اصلاح کي قابل بڻائي ٿو ۽ اهڙيء طرح وڌيڪ صحيح سوالن جي منصوبن کي چونڊڻ ۾ مدد ڪري ٿو. جڏهن ته، نسخي 2016 جي طور تي، اهو اڪثر ڪري ڪافي ڊگهي مجموعي سوال جي عمل جي وقت تي منفي اثر رکي ٿو.
انهي سان گڏ، ڪيترن ئي انڊيڪسس سان سسٽم لاء (مثال طور، 1C ڊيٽابيس لاء)، مان سفارش ڪريان ٿو چالو ڪرڻ جو نشان پرچم 2330، جيڪو انڊيڪس استعمال جي مجموعي کي غير فعال ڪري ٿو، جيڪو عام طور تي سسٽم تي مثبت اثر رکي ٿو.
ٽريس جھنڊو بابت وڌيڪ معلومات لاء، ڏسو هتي
مٿي ڏنل لنڪ مان، اهو پڻ ضروري آهي ته MS SQL سرور جي ورجن ۽ بلڊز تي غور ڪيو وڃي، جيئن نون ورزن لاءِ، ڪجهه ٽريس فليگ ڊفالٽ طور فعال ڪيا ويندا آهن يا انهن جو ڪو اثر نه هوندو آهي.
توهان ترتيب سان DBCC TRACEON ۽ DBCC TRACEOFF حڪمن سان ٽريس پرچم کي آن ۽ آف ڪري سگھو ٿا. وڌيڪ تفصيل لاءِ ڏسو هتي
توهان DBCC TRACESTATUS ڪمانڊ استعمال ڪندي ٽريس پرچم جي حيثيت حاصل ڪري سگهو ٿا: подробнее
MS SQL سرور سروس جي آٽو سٹارٽ ۾ شامل ٿيڻ لاءِ ٽريس جھنڊو شامل ڪرڻ لاءِ، توھان کي لازمي طور تي SQL سرور ڪنفيگريشن مئنيجر ڏانھن وڃڻ گھرجي ۽ سروس پراپرٽيز ۾ -T ذريعي ھنن جھنڊن کي شامل ڪرڻ گھرجي:
MS SQL سرور مانيٽرنگ جا ڪجھ حصا. ٽريس پرچم سيٽنگ لاء هدايتون

نتيجو

هن آرٽيڪل ۾، MS SQL سرور جي نگراني جي ڪجهه حصن جو تجزيو ڪيو ويو، جنهن جي مدد سان توهان جلدي سڃاڻي سگهو ٿا RAM جي کوٽ ۽ مفت CPU وقت، ۽ انهي سان گڏ ٻيا ڪيترائي گهٽ واضح مسئلا. سڀ کان وڌيڪ عام طور تي استعمال ٿيل ٽريڪ پرچم جو جائزو ورتو ويو آهي.

ذريعن:

» SQL سرور انتظار جا انگ اکر
» SQL Server انگن اکرن جو انتظار ڪريو يا مھرباني ڪري مون کي ٻڌايو ته اھو ڪٿي ڏکوئيندڙ آھي
» سسٽم جو ڏيک sys.dm_os_schedulers
» MS SQL سرور ڊيٽابيس کي مانيٽر ڪرڻ لاء زيبڪس استعمال ڪندي
» SQL طرز زندگي
» نشانو پرچم
» sql.ru

جو ذريعو: www.habr.com

تبصرو شامل ڪريو