MS SQL সার্ভার পর্যবেক্ষণের কিছু দিক। ট্রেস পতাকা সেট করার জন্য নির্দেশিকা

ভূমিকা

প্রায়শই, MS SQL সার্ভার DBMS-এর ব্যবহারকারী, ডেভেলপার এবং অ্যাডমিনিস্ট্রেটররা ডাটাবেস বা DBMS সামগ্রিকভাবে পারফরম্যান্স সমস্যার সম্মুখীন হয়, তাই MS SQL সার্ভার মনিটরিং খুবই প্রাসঙ্গিক।
এই নিবন্ধটি নিবন্ধের একটি সংযোজন MS SQL সার্ভার ডাটাবেস নিরীক্ষণ করতে Zabbix ব্যবহার করে এবং এটি MS SQL সার্ভার নিরীক্ষণের কিছু দিক কভার করবে, বিশেষ করে: কোন সংস্থানগুলি অনুপস্থিত তা দ্রুত কীভাবে নির্ধারণ করা যায়, সেইসাথে ট্রেস ফ্ল্যাগ সেট করার জন্য সুপারিশগুলি।
নিম্নলিখিত স্ক্রিপ্টগুলি কাজ করার জন্য, আপনাকে নিম্নলিখিত হিসাবে পছন্দসই ডাটাবেসে একটি inf স্কিমা তৈরি করতে হবে:
একটি ইনফ স্কিমা তৈরি করা হচ্ছে

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

RAM এর অভাব সনাক্ত করার পদ্ধতি

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 এর থেকে বেশি বা সমান হয়, তাহলে অপেক্ষার পরিসংখ্যান পরীক্ষা করা উচিত।
অপেক্ষার পরিসংখ্যানের মাধ্যমে RAM এর অভাব নির্ণয় করতে, আসুন inf.vWaits ভিউ তৈরি করি:
inf.vWaits ভিউ তৈরি করা হচ্ছে

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 সূচকগুলিতে মনোযোগ দিতে হবে। যদি সেগুলি তাদের সামগ্রিকতায় তাৎপর্যপূর্ণ হয়, তাহলে এমএস এসকিউএল সার্ভার উদাহরণের জন্য পর্যাপ্ত র‌্যাম না থাকার সম্ভাবনা খুব বেশি। প্রতিটি সিস্টেমের জন্য উল্লেখযোগ্য মান পৃথকভাবে নির্ধারিত হয়। যাইহোক, আপনি নিম্নলিখিত দিয়ে শুরু করতে পারেন: শতাংশ>=1 এবং AvgWait_S>=0.005।
একটি মনিটরিং সিস্টেমে সূচক আউটপুট করতে (উদাহরণস্বরূপ, Zabbix), আপনি নিম্নলিখিত দুটি প্রশ্ন তৈরি করতে পারেন:

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 সার্ভারের উদাহরণের জন্য পর্যাপ্ত RAM আছে কিনা তা উপসংহারে আসতে পারি।

CPU ওভারলোড সনাক্তকরণ পদ্ধতি

প্রসেসর সময়ের অভাব সনাক্ত করতে, 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;

এই সূচকের জন্য প্রাপ্ত মানগুলির গতিশীলতার উপর ভিত্তি করে, আমরা এমএস এসকিউএল সার্ভারের উদাহরণের জন্য যথেষ্ট প্রসেসর সময় (সিপিইউ কোরের সংখ্যা) আছে কিনা তা উপসংহারে আসতে পারি।
যাইহোক, এটি মনে রাখা গুরুত্বপূর্ণ যে অনুরোধগুলি নিজেরাই একবারে একাধিক থ্রেডের অনুরোধ করতে পারে৷ এবং কখনও কখনও অপ্টিমাইজার নিজেই প্রশ্নের জটিলতা সঠিকভাবে অনুমান করতে পারে না। তারপর অনুরোধটি অনেকগুলি থ্রেড বরাদ্দ করা হতে পারে যা প্রদত্ত সময়ে একই সময়ে প্রক্রিয়া করা যাবে না। এবং এটি প্রসেসরের সময়ের অভাবের সাথে যুক্ত এক ধরণের অপেক্ষার কারণ হয় এবং নির্দিষ্ট সিপিইউ কোর ব্যবহার করে এমন শিডিউলারের জন্য সারির বৃদ্ধি, যেমন রানেবল_টাস্ক_কাউন্ট সূচক এই ধরনের পরিস্থিতিতে বৃদ্ধি পাবে।
এই ক্ষেত্রে, সিপিইউ কোরের সংখ্যা বাড়ানোর আগে, এমএস এসকিউএল সার্ভারের উদাহরণের সমান্তরাল বৈশিষ্ট্যগুলি সঠিকভাবে কনফিগার করা প্রয়োজন এবং 2016 সংস্করণ থেকে, প্রয়োজনীয় ডাটাবেসের সমান্তরাল বৈশিষ্ট্যগুলি সঠিকভাবে কনফিগার করা প্রয়োজন:



এখানে আপনার নিম্নলিখিত পরামিতিগুলিতে মনোযোগ দেওয়া উচিত:

1. সমান্তরালতার সর্বোচ্চ ডিগ্রি - প্রতিটি অনুরোধে বরাদ্দ করা যেতে পারে এমন সর্বাধিক সংখ্যক থ্রেড সেট করে (ডিফল্টটি 0 - শুধুমাত্র অপারেটিং সিস্টেম নিজেই এবং MS SQL সার্ভারের সংস্করণ দ্বারা সীমাবদ্ধ)
2. সমান্তরালতার জন্য খরচ থ্রেশহোল্ড - সমান্তরালতার আনুমানিক খরচ (ডিফল্ট হল 5)
3. সর্বোচ্চ DOP - ডেটাবেস স্তরে প্রতিটি প্রশ্নের জন্য বরাদ্দ করা যেতে পারে এমন সর্বাধিক সংখ্যক থ্রেড সেট করে (কিন্তু "সমান্তরালতার সর্বোচ্চ ডিগ্রি" বৈশিষ্ট্যের মানের চেয়ে বেশি নয়) (ডিফল্ট হল 0 - শুধুমাত্র অপারেটিং সিস্টেম দ্বারা সীমাবদ্ধ এবং MS SQL সার্ভারের সংস্করণ, সেইসাথে MS SQL সার্ভারের সমগ্র উদাহরণের "সর্বোচ্চ ডিগ্রি অফ প্যারালেলিজম" বৈশিষ্ট্যের উপর সীমাবদ্ধতা)

এখানে সমস্ত ক্ষেত্রে সমানভাবে ভাল রেসিপি দেওয়া অসম্ভব, যেমন আপনাকে ভারী প্রশ্নগুলি বিশ্লেষণ করতে হবে।
আমার নিজের অভিজ্ঞতা থেকে, আমি সমান্তরাল বৈশিষ্ট্য সেট আপ করার জন্য OLTP সিস্টেমের জন্য নিম্নলিখিত অ্যালগরিদম অ্যাকশনের সুপারিশ করছি:

1. প্রথমে প্যারালেলিজম অক্ষম করুন ইনস্ট্যান্স-ওয়াইড প্যারালালিজমের সর্বোচ্চ ডিগ্রি 1 এ সেট করে
2. সবচেয়ে ভারী অনুরোধগুলি বিশ্লেষণ করুন এবং তাদের জন্য থ্রেডের সর্বোত্তম সংখ্যা নির্বাচন করুন
3. ধাপ 2 থেকে প্রাপ্ত থ্রেডের নির্বাচিত সর্বোত্তম সংখ্যায় সমান্তরালতার সর্বোচ্চ ডিগ্রি সেট করুন এবং নির্দিষ্ট ডাটাবেসের জন্য প্রতিটি ডাটাবেসের জন্য ধাপ 2 থেকে প্রাপ্ত সর্বোচ্চ DOP মান সেট করুন।
4. সবচেয়ে ভারী অনুরোধগুলি বিশ্লেষণ করুন এবং মাল্টিথ্রেডিংয়ের নেতিবাচক প্রভাব চিহ্নিত করুন। যদি তা হয়, তাহলে সমান্তরালতার জন্য খরচ থ্রেশহোল্ড বাড়ান।
   1C, মাইক্রোসফ্ট সিআরএম এবং মাইক্রোসফ্ট এনএভির মতো সিস্টেমের জন্য, বেশিরভাগ ক্ষেত্রে, মাল্টিথ্রেডিং নিষিদ্ধ করা উপযুক্ত

এছাড়াও, যদি একটি স্ট্যান্ডার্ড সংস্করণ থাকে, তবে বেশিরভাগ ক্ষেত্রে মাল্টিথ্রেডিংয়ের নিষেধাজ্ঞা উপযুক্ত কারণ এই সংস্করণটি সিপিইউ কোরের সংখ্যায় সীমিত।
OLAP সিস্টেমের জন্য, উপরে বর্ণিত অ্যালগরিদম উপযুক্ত নয়।
আমার নিজের অভিজ্ঞতা থেকে, আমি সমান্তরাল বৈশিষ্ট্যগুলি সেট আপ করার জন্য OLAP সিস্টেমের জন্য নিম্নলিখিত অ্যালগরিদমের অ্যালগরিদম সুপারিশ করছি:

1. সবচেয়ে ভারী অনুরোধগুলি বিশ্লেষণ করুন এবং তাদের জন্য থ্রেডের সর্বোত্তম সংখ্যা নির্বাচন করুন
2. ধাপ 1 থেকে প্রাপ্ত থ্রেডের নির্বাচিত সর্বোত্তম সংখ্যায় সমান্তরালতার সর্বোচ্চ ডিগ্রি সেট করুন এবং নির্দিষ্ট ডাটাবেসের জন্য প্রতিটি ডাটাবেসের জন্য ধাপ 1 থেকে প্রাপ্ত সর্বোচ্চ DOP মান সেট করুন।
3. সবচেয়ে ভারী প্রশ্নগুলি বিশ্লেষণ করুন এবং সীমিত একত্রিতার নেতিবাচক প্রভাব চিহ্নিত করুন। যদি তা হয়, তাহলে হয় সমান্তরাল মানের জন্য খরচ থ্রেশহোল্ড কমিয়ে দিন, অথবা এই অ্যালগরিদমের 1-2 ধাপগুলি পুনরাবৃত্তি করুন

অর্থাৎ, OLTP সিস্টেমের জন্য আমরা একক-থ্রেডিং থেকে মাল্টি-থ্রেডিং-এ যাই, এবং OLAP-সিস্টেমের জন্য, বিপরীতে, আমরা মাল্টি-থ্রেডিং থেকে একক-থ্রেডিং-এ যাই। এইভাবে, আপনি একটি নির্দিষ্ট ডাটাবেস এবং MS SQL সার্ভারের সম্পূর্ণ উদাহরণ উভয়ের জন্য সর্বোত্তম সমান্তরাল সেটিংস চয়ন করতে পারেন।
এটি বোঝাও গুরুত্বপূর্ণ যে MS SQL সার্ভারের কর্মক্ষমতা নিরীক্ষণের ফলাফলের উপর ভিত্তি করে সমান্তরাল বৈশিষ্ট্যগুলির সেটিংস সময়ের সাথে পরিবর্তন করা প্রয়োজন।

ট্রেস পতাকা সেট করার জন্য নির্দেশিকা

আমার নিজের অভিজ্ঞতা এবং আমার সহকর্মীদের অভিজ্ঞতা থেকে, সর্বোত্তম কর্মক্ষমতার জন্য, আমি 2008-2016 সংস্করণের জন্য MS SQL সার্ভার পরিষেবার রান স্তরে নিম্নলিখিত ট্রেস ফ্ল্যাগগুলি সেট করার সুপারিশ করছি:

1. 610 - সূচীকৃত টেবিলে সন্নিবেশের লগিং হ্রাস। অনেক রেকর্ড এবং অনেক লেনদেন সহ টেবিলে সন্নিবেশ করতে সাহায্য করতে পারে, ঘন ঘন দীর্ঘ WRITELOG ইনডেক্সে পরিবর্তনের জন্য অপেক্ষা করে
2. 1117 - যদি একটি ফাইলগ্রুপের একটি ফাইল স্বয়ংক্রিয় বৃদ্ধির থ্রেশহোল্ড প্রয়োজনীয়তা পূরণ করে, তাহলে ফাইলগ্রুপের সমস্ত ফাইল বৃদ্ধি পাবে
3. 1118 - সমস্ত বস্তুকে বিভিন্ন বিস্তৃতিতে অবস্থিত হতে বাধ্য করে (মিশ্র ব্যাপ্তির নিষেধাজ্ঞা), যা এসজিএএম পৃষ্ঠাটি স্ক্যান করার প্রয়োজনীয়তাকে কমিয়ে দেয়, যা মিশ্র মাত্রা ট্র্যাক করতে ব্যবহৃত হয়
4. 1224 - লক সংখ্যার উপর ভিত্তি করে লক বৃদ্ধি নিষ্ক্রিয় করে। যাইহোক, অত্যধিক মেমরি ব্যবহার লক বৃদ্ধি ট্রিগার করতে পারে
5. 2371 - স্থির স্বয়ংক্রিয় পরিসংখ্যান আপডেট থ্রেশহোল্ডকে গতিশীল স্বয়ংক্রিয় পরিসংখ্যান আপডেট থ্রেশহোল্ডে পরিবর্তন করে। বড় টেবিলের জন্য ক্যোয়ারী প্ল্যান আপডেট করার জন্য গুরুত্বপূর্ণ, যেখানে রেকর্ডের একটি ভুল গণনা ভুল এক্সিকিউশন প্ল্যানে পরিণত হয়
6. 3226 - ত্রুটি লগে ব্যাকআপ সাফল্যের বার্তাগুলিকে দমন করে৷
7. 4199 - CUs এবং SQL সার্ভার সার্ভিস প্যাকগুলিতে প্রকাশিত ক্যোয়ারী অপ্টিমাইজারের পরিবর্তনগুলি অন্তর্ভুক্ত করে
8. 6532-6534 - স্থানিক ডেটা টাইপের উপর ক্যোয়ারী অপারেশনের জন্য কর্মক্ষমতা উন্নতি অন্তর্ভুক্ত করে
9. 8048 - NUMA পার্টিশন করা মেমরি অবজেক্টকে CPU পার্টিশন করা বস্তুতে রূপান্তর করে
10. 8780 - ক্যোয়ারী পরিকল্পনার জন্য অতিরিক্ত সময় বরাদ্দ সক্ষম করে। এই পতাকা ছাড়া কিছু অনুরোধ প্রত্যাখ্যান করা যেতে পারে কারণ তাদের একটি ক্যোয়ারী প্ল্যান নেই (খুব বিরল বাগ)
11. 8780 - 9389 - ব্যাচ মোড স্টেটমেন্টের জন্য অতিরিক্ত গতিশীল অনুদান মেমরি বাফার সক্ষম করে, যা ব্যাচ মোড অপারেটরকে আরও মেমরির অনুরোধ করতে এবং আরও মেমরি উপলব্ধ থাকলে টেম্পডিবিতে ডেটা সরানো এড়াতে দেয়

এছাড়াও 2016 এর আগে, এটি ট্রেস ফ্ল্যাগ 2301 সক্ষম করার জন্য দরকারী, যা বর্ধিত সিদ্ধান্ত সমর্থন অপ্টিমাইজেশান সক্ষম করে এবং এইভাবে আরও সঠিক ক্যোয়ারী পরিকল্পনা বেছে নিতে সহায়তা করে। যাইহোক, সংস্করণ 2016 হিসাবে, এটি প্রায়ই বেশ দীর্ঘ সামগ্রিক ক্যোয়ারী কার্যকর করার সময়গুলির উপর একটি নেতিবাচক প্রভাব ফেলে।
এছাড়াও, অনেকগুলি সূচক সহ সিস্টেমগুলির জন্য (উদাহরণস্বরূপ, 1C ডেটাবেসের জন্য), আমি ট্রেস ফ্ল্যাগ 2330 সক্ষম করার পরামর্শ দিই, যা সূচকের ব্যবহার সংগ্রহকে অক্ষম করে, যা সাধারণত সিস্টেমে ইতিবাচক প্রভাব ফেলে।
ট্রেস পতাকা সম্পর্কে আরো তথ্যের জন্য, দেখুন এখানে
উপরের লিঙ্ক থেকে, MS SQL সার্ভারের সংস্করণ এবং বিল্ডগুলি বিবেচনা করাও গুরুত্বপূর্ণ, কারণ নতুন সংস্করণগুলির জন্য, কিছু ট্রেস ফ্ল্যাগ ডিফল্টরূপে সক্রিয় থাকে বা কোন প্রভাব নেই৷
আপনি যথাক্রমে DBCC TRACEON এবং DBCC TRACEOFF কমান্ডের সাহায্যে ট্রেস পতাকা চালু এবং বন্ধ করতে পারেন। আরো বিস্তারিত জানার জন্য দেখুন এখানে
আপনি DBCC TRACESTATUS কমান্ড ব্যবহার করে ট্রেস পতাকার স্থিতি পেতে পারেন: আরো তথ্য
MS SQL সার্ভার পরিষেবার অটোস্টার্টে ট্রেস ফ্ল্যাগগুলি অন্তর্ভুক্ত করার জন্য, আপনাকে অবশ্যই SQL সার্ভার কনফিগারেশন ম্যানেজারে যেতে হবে এবং পরিষেবা বৈশিষ্ট্যগুলিতে -T-এর মাধ্যমে এই ট্রেস পতাকাগুলি যুক্ত করতে হবে:

ফলাফল

এই নিবন্ধে, এমএস এসকিউএল সার্ভার নিরীক্ষণের কিছু দিক বিশ্লেষণ করা হয়েছে, যার সাহায্যে আপনি দ্রুত র‌্যাম এবং ফ্রি সিপিইউ সময়ের অভাব, সেইসাথে অন্যান্য অনেক কম স্পষ্ট সমস্যা সনাক্ত করতে পারেন। সর্বাধিক ব্যবহৃত ট্রেস পতাকা পর্যালোচনা করা হয়েছে.

উত্স:

» SQL সার্ভার অপেক্ষা পরিসংখ্যান
» এসকিউএল সার্ভারের পরিসংখ্যান অপেক্ষা করুন বা দয়া করে আমাকে বলুন কোথায় এটি ব্যাথা করে
» সিস্টেম ভিউ sys.dm_os_schedulers
» MS SQL সার্ভার ডাটাবেস নিরীক্ষণ করতে Zabbix ব্যবহার করে
» এসকিউএল লাইফস্টাইল
» ট্রেস পতাকা
» sql.ru

উত্স: www.habr.com