🥇 MS SQL سرور کی نگرانی کے کچھ پہلو۔ ٹریس جھنڈوں کی ترتیب کے لیے رہنما خطوط

کردار

اکثر، MS SQL Server DBMS کے صارفین، ڈویلپرز اور منتظمین کو ڈیٹا بیس یا مجموعی طور پر DBMS کی کارکردگی کے مسائل کا سامنا کرنا پڑتا ہے، اس لیے MS SQL سرور کی نگرانی بہت متعلقہ ہے۔
یہ مضمون مضمون میں ایک اضافہ ہے۔ MS SQL سرور ڈیٹا بیس کی نگرانی کے لیے Zabbix کا استعمال اور یہ MS SQL سرور کی نگرانی کے کچھ پہلوؤں کا احاطہ کرے گا، خاص طور پر: فوری طور پر یہ کیسے طے کیا جائے کہ کون سے وسائل غائب ہیں، نیز ٹریس جھنڈوں کو ترتیب دینے کی سفارشات۔
درج ذیل اسکرپٹس کے کام کرنے کے لیے، آپ کو مطلوبہ ڈیٹا بیس میں درج ذیل کے طور پر ایک inf اسکیما بنانا ہوگا۔
ایک 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;

پھر آپ اس بات کا تعین کر سکتے ہیں کہ ایم ایس ایس کیو ایل سرور کی ایک مثال درج ذیل استفسار کے ذریعے اس کے لیے مختص کردہ تمام میموری استعمال کر لیتی ہے۔

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];

اس صورت میں، آپ درج ذیل استفسار سے RAM کی کمی کا تعین کر سکتے ہیں۔

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

یہاں آپ کو اشارے فیصد اور AvgWait_S پر توجہ دینے کی ضرورت ہے۔ اگر وہ اپنے مجموعی طور پر اہم ہیں، تو اس بات کا بہت زیادہ امکان ہے کہ MS SQL سرور مثال کے لیے کافی RAM نہیں ہے۔ اہم اقدار کا تعین ہر نظام کے لیے انفرادی طور پر کیا جاتا ہے۔ تاہم، آپ درج ذیل کے ساتھ شروع کر سکتے ہیں: فیصد>=1 اور AvgWait_S>=0.005۔
مانیٹرنگ سسٹم (مثال کے طور پر، Zabbix) میں اشارے آؤٹ پٹ کرنے کے لیے، آپ درج ذیل دو سوالات بنا سکتے ہیں:

کتنے قسم کے انتظار پر RAM فیصد میں قابض ہے (اس قسم کے تمام انتظاروں کا مجموعہ):

select coalesce(sum([Percentage]), 0.00) as [Percentage]
from [inf].[vWaits]
       where [WaitType] in (
           'PAGEIOLATCH_XX',
           'RESOURCE_SEMAPHORE',
            'RESOURCE_SEMAPHORE_QUERY_COMPILE'
  );

کتنی 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 سرور کی مثال کے لیے کافی RAM موجود ہے۔

CPU اوورلوڈ کا پتہ لگانے کا طریقہ

پروسیسر کے وقت کی کمی کی نشاندہی کرنے کے لیے، sys.dm_os_schedulers سسٹم ویو استعمال کرنا کافی ہے۔ یہاں، اگر رن ایبل_ٹاسک_کاؤنٹ مسلسل 1 سے زیادہ ہے، تو اس بات کا بہت زیادہ امکان ہے کہ MS SQL سرور مثال کے لیے کور کی تعداد کافی نہیں ہے۔
مانیٹرنگ سسٹم (مثال کے طور پر، Zabbix) میں اشارے کو آؤٹ پٹ کرنے کے لیے، آپ درج ذیل استفسار بنا سکتے ہیں:

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

اس اشارے کے لیے حاصل کردہ اقدار کی حرکیات کی بنیاد پر، ہم یہ نتیجہ اخذ کر سکتے ہیں کہ آیا MS SQL سرور کی مثال کے لیے پروسیسر کا کافی وقت (سی پی یو کور کی تعداد) موجود ہے۔
تاہم، اس حقیقت کو ذہن میں رکھنا ضروری ہے کہ درخواستیں خود ایک ساتھ متعدد تھریڈز کی درخواست کر سکتی ہیں۔ اور بعض اوقات اصلاح کنندہ خود استفسار کی پیچیدگی کا صحیح اندازہ نہیں لگا سکتا۔ پھر درخواست کو بہت سارے دھاگے مختص کیے جاسکتے ہیں جن پر دیے گئے وقت پر ایک ہی وقت میں کارروائی نہیں کی جاسکتی ہے۔ اور یہ پروسیسر کے وقت کی کمی سے وابستہ ایک قسم کے انتظار کا سبب بنتا ہے، اور مخصوص CPU کور استعمال کرنے والے شیڈولرز کے لیے قطار میں اضافہ، یعنی رن ایبل_ٹاسک_کاؤنٹ انڈیکیٹر ایسے حالات میں بڑھے گا۔
اس صورت میں، CPU کور کی تعداد بڑھانے سے پہلے، یہ ضروری ہے کہ خود MS SQL سرور مثال کے متوازی خصوصیات کو درست طریقے سے ترتیب دیں، اور 2016 کے ورژن سے، مطلوبہ ڈیٹا بیس کی متوازی خصوصیات کو درست طریقے سے ترتیب دیں۔

یہاں آپ کو مندرجہ ذیل پیرامیٹرز پر توجہ دینا چاہئے:

متوازی کی زیادہ سے زیادہ ڈگری - دھاگوں کی زیادہ سے زیادہ تعداد کا تعین کرتا ہے جو ہر درخواست کے لیے مختص کیے جا سکتے ہیں (پہلے سے طے شدہ 0 ہے - صرف خود آپریٹنگ سسٹم اور MS SQL سرور کے ایڈیشن سے محدود)
متوازی کے لیے لاگت کی حد - متوازی کی تخمینی لاگت (پہلے سے طے شدہ 5 ہے)
میکس DOP - دھاگوں کی زیادہ سے زیادہ تعداد کو سیٹ کرتا ہے جو ڈیٹا بیس کی سطح پر ہر استفسار کے لیے مختص کیے جا سکتے ہیں (لیکن "متوازی کی زیادہ سے زیادہ ڈگری" پراپرٹی کی قدر سے زیادہ نہیں) (پہلے سے طے شدہ 0 ہے - صرف آپریٹنگ سسٹم کے ذریعہ محدود ہے اور ایم ایس ایس کیو ایل سرور کا ایڈیشن، نیز ایم ایس ایس کیو ایل سرور کی پوری مثال کی "متوازی کی زیادہ سے زیادہ ڈگری" کی خاصیت پر پابندی)

یہاں تمام صورتوں کے لیے یکساں عمدہ نسخہ دینا ناممکن ہے، یعنی آپ کو بھاری سوالات کا تجزیہ کرنے کی ضرورت ہے۔
میرے اپنے تجربے سے، میں متوازی خصوصیات کو ترتیب دینے کے لیے او ایل ٹی پی سسٹمز کے لیے درج ذیل الگورتھم کا مشورہ دیتا ہوں:

سب سے پہلے متوازی کی زیادہ سے زیادہ ڈگری کو 1 پر سیٹ کرکے متوازی کو غیر فعال کریں۔
سب سے بھاری درخواستوں کا تجزیہ کریں اور ان کے لیے تھریڈز کی زیادہ سے زیادہ تعداد کا انتخاب کریں۔
متوازی کی زیادہ سے زیادہ ڈگری کو مرحلہ 2 سے حاصل کردہ دھاگوں کی منتخب کردہ زیادہ سے زیادہ تعداد پر سیٹ کریں، اور مخصوص ڈیٹا بیس کے لیے ہر ڈیٹا بیس کے لیے مرحلہ 2 سے حاصل کردہ زیادہ سے زیادہ DOP قدر سیٹ کریں۔
سب سے بھاری درخواستوں کا تجزیہ کریں اور ملٹی تھریڈنگ کے منفی اثر کی نشاندہی کریں۔ اگر یہ ہے، تو متوازی کے لیے لاگت کی حد میں اضافہ کریں۔
1C، Microsoft CRM اور Microsoft NAV جیسے سسٹمز کے لیے، زیادہ تر معاملات میں، ملٹی تھریڈنگ کی ممانعت مناسب ہے۔

اس کے علاوہ، اگر معیاری ایڈیشن ہے، تو زیادہ تر معاملات میں ملٹی تھریڈنگ کی ممانعت اس حقیقت کی وجہ سے موزوں ہے کہ یہ ایڈیشن CPU کور کی تعداد میں محدود ہے۔
OLAP سسٹمز کے لیے، اوپر بیان کردہ الگورتھم موزوں نہیں ہے۔
میرے اپنے تجربے سے، میں متوازی خصوصیات کو ترتیب دینے کے لیے OLAP سسٹم کے لیے درج ذیل الگورتھم کی کارروائیوں کی سفارش کرتا ہوں:

سب سے بھاری درخواستوں کا تجزیہ کریں اور ان کے لیے تھریڈز کی زیادہ سے زیادہ تعداد کا انتخاب کریں۔
متوازی کی زیادہ سے زیادہ ڈگری کو مرحلہ 1 سے حاصل کردہ دھاگوں کی منتخب کردہ زیادہ سے زیادہ تعداد پر سیٹ کریں، اور مخصوص ڈیٹا بیس کے لیے ہر ڈیٹا بیس کے لیے مرحلہ 1 سے حاصل کردہ زیادہ سے زیادہ DOP قدر سیٹ کریں۔
سب سے بھاری سوالات کا تجزیہ کریں اور ہم آہنگی کو محدود کرنے کے منفی اثر کی نشاندہی کریں۔ اگر ایسا ہے، تو یا تو متوازی قدر کے لیے لاگت کی حد کو کم کریں، یا اس الگورتھم کے 1-2 مراحل کو دہرائیں۔

یعنی، OLTP سسٹمز کے لیے ہم سنگل تھریڈنگ سے ملٹی تھریڈنگ کی طرف جاتے ہیں، اور OLAP سسٹمز کے لیے، اس کے برعکس، ہم ملٹی تھریڈنگ سے سنگل تھریڈنگ کی طرف جاتے ہیں۔ اس طرح، آپ ایک مخصوص ڈیٹا بیس اور MS SQL سرور کی پوری مثال دونوں کے لیے بہترین ہم آہنگی کی ترتیبات کا انتخاب کر سکتے ہیں۔
یہ سمجھنا بھی ضروری ہے کہ MS SQL سرور کی کارکردگی کی نگرانی کے نتائج کی بنیاد پر متوازی خصوصیات کی ترتیبات کو وقت کے ساتھ تبدیل کرنے کی ضرورت ہے۔

ٹریس جھنڈوں کو ترتیب دینے کے لئے رہنما خطوط

میرے اپنے تجربے اور اپنے ساتھیوں کے تجربے سے، بہترین کارکردگی کے لیے، میں MS SQL سرور سروس کے ورژن 2008-2016 کے لیے درج ذیل ٹریس جھنڈوں کو ترتیب دینے کی تجویز کرتا ہوں:

610 - انڈیکسڈ ٹیبلز میں داخلوں کی لاگنگ میں کمی۔ کئی ریکارڈوں اور بہت سے لین دین کے ساتھ جدولوں میں داخل کرنے میں مدد کر سکتے ہیں، بار بار WRITELOG اشاریہ جات میں تبدیلیوں کا انتظار کرتا ہے۔
1117 - اگر فائل گروپ میں کوئی فائل آٹو گروتھ تھریشولڈ کی ضروریات کو پورا کرتی ہے، تو فائل گروپ میں تمام فائلیں بڑھ جاتی ہیں
1118 - تمام اشیاء کو مختلف حدود میں واقع ہونے پر مجبور کرتا ہے (مخلوط حدود کی ممانعت)، جس سے ایس جی اے ایم صفحہ کو اسکین کرنے کی ضرورت کم ہوتی ہے، جو مخلوط حدود کو ٹریک کرنے کے لیے استعمال ہوتا ہے۔
1224 - تالے کی تعداد کی بنیاد پر لاک بڑھانے کو غیر فعال کرتا ہے۔ تاہم، ضرورت سے زیادہ میموری کا استعمال لاک میں اضافے کو متحرک کر سکتا ہے۔
2371 - فکسڈ خودکار شماریات کی تازہ کاری کی حد کو متحرک خودکار اعدادوشمار کی تازہ کاری کی حد میں تبدیل کرتا ہے۔ بڑے ٹیبلز کے لیے استفسار کے منصوبوں کو اپ ڈیٹ کرنے کے لیے اہم، جہاں ریکارڈز کی غلط گنتی کے نتیجے میں عمل درآمد کے منصوبے غلط ہوتے ہیں۔
3226 - خرابی کے لاگ میں بیک اپ کامیابی کے پیغامات کو دباتا ہے۔
4199 - CUs اور SQL Server Service Packs میں جاری کردہ استفسار آپٹیمائزر میں تبدیلیاں شامل ہیں
6532-6534 - مقامی ڈیٹا کی اقسام پر استفسار کی کارروائیوں کے لیے کارکردگی میں بہتری شامل ہے
8048 - NUMA تقسیم شدہ میموری اشیاء کو CPU تقسیم شدہ چیزوں میں تبدیل کرتا ہے۔
8780 - استفسار کی منصوبہ بندی کے لیے اضافی وقت مختص کرنے کے قابل بناتا ہے۔ اس جھنڈے کے بغیر کچھ درخواستیں مسترد کی جا سکتی ہیں کیونکہ ان کے پاس استفسار کا منصوبہ نہیں ہے (بہت نایاب بگ)
8780 - 9389 - بیچ موڈ اسٹیٹمنٹس کے لیے اضافی ڈائنامک گرانٹ میموری بفر کو فعال کرتا ہے، جو بیچ موڈ آپریٹر کو اضافی میموری کی درخواست کرنے اور اضافی میموری دستیاب ہونے کی صورت میں ڈیٹا کو tempdb میں منتقل کرنے سے بچنے کی اجازت دیتا ہے۔

2016 سے پہلے بھی، ٹریس فلیگ 2301 کو فعال کرنا کارآمد ہے، جو بہتر فیصلہ سازی کی حمایت کو قابل بناتا ہے اور اس طرح مزید درست استفسار کے منصوبوں کو منتخب کرنے میں مدد کرتا ہے۔ تاہم، ورژن 2016 کے مطابق، اس کا اکثر مجموعی طور پر طویل استفسار کے عمل کے اوقات پر منفی اثر پڑتا ہے۔
نیز، بہت سارے اشاریہ جات والے سسٹمز کے لیے (مثال کے طور پر، 1C ڈیٹا بیس کے لیے)، میں ٹریس فلیگ 2330 کو فعال کرنے کی تجویز کرتا ہوں، جو انڈیکس کے استعمال کو جمع کرنے کو غیر فعال کر دیتا ہے، جس کا عام طور پر سسٹم پر مثبت اثر پڑتا ہے۔
ٹریس جھنڈوں کے بارے میں مزید معلومات کے لیے، دیکھیں یہاں
اوپر دیے گئے لنک سے، یہ بھی ضروری ہے کہ MS SQL سرور کے ورژنز اور بلڈز پر غور کیا جائے، جیسا کہ نئے ورژنز کے لیے، کچھ ٹریس فلیگ ڈیفالٹ کے طور پر فعال ہوتے ہیں یا ان کا کوئی اثر نہیں ہوتا۔
آپ بالترتیب DBCC TRACEON اور DBCC TRACEOFF کمانڈز کے ساتھ ٹریس فلیگ کو آن اور آف کر سکتے ہیں۔ مزید تفصیلات کے لیے دیکھیں یہاں
آپ DBCC TRACESTATUS کمانڈ کا استعمال کرتے ہوئے ٹریس جھنڈوں کی حیثیت حاصل کر سکتے ہیں: مزید
MS SQL سرور سروس کے آٹو سٹارٹ میں ٹریس جھنڈوں کو شامل کرنے کے لیے، آپ کو SQL Server Configuration Manager پر جانا چاہیے اور سروس کی خصوصیات میں -T کے ذریعے ان ٹریس جھنڈوں کو شامل کرنا چاہیے:

کے نتائج

اس آرٹیکل میں ایم ایس ایس کیو ایل سرور کی نگرانی کے کچھ پہلوؤں کا تجزیہ کیا گیا ہے، جن کی مدد سے آپ ریم کی کمی اور مفت سی پی یو ٹائم کے ساتھ ساتھ بہت سے دیگر کم واضح مسائل کی فوری نشاندہی کر سکتے ہیں۔ سب سے زیادہ استعمال ہونے والے ٹریس جھنڈوں کا جائزہ لیا گیا ہے۔

ذرائع کے مطابق:

» SQL سرور انتظار کے اعدادوشمار
» ایس کیو ایل سرور کے اعدادوشمار کا انتظار کریں یا براہ کرم مجھے بتائیں کہ یہ کہاں تکلیف دہ ہے۔
» سسٹم ویو sys.dm_os_schedulers
» MS SQL سرور ڈیٹا بیس کی نگرانی کے لیے Zabbix کا استعمال
» ایس کیو ایل طرز زندگی
» جھنڈوں کا سراغ لگانا
» sql.ru

ماخذ: www.habr.com

MS SQL سرور کی نگرانی کے کچھ پہلو۔ ٹریس جھنڈوں کو ترتیب دینے کے لئے رہنما خطوط