ProHoster > بلاګ > اداره > د MS SQL سرور څارنې ځینې اړخونه. د ټریس بیرغونو تنظیم کولو لپاره لارښوونې

د MS SQL سرور څارنې ځینې اړخونه. د ټریس بیرغونو تنظیم کولو لپاره لارښوونې

وړاندیز

ډیری وختونه، د MS SQL Server DBMS کاروونکي، پراختیا کونکي او مدیران د ډیټابیس یا DBMS د فعالیت ستونزې سره مخ کیږي، نو د MS SQL سرور څارنه خورا اړونده ده.
دا مقاله د مقالې اضافه ده د MS SQL سرور ډیټابیس نظارت کولو لپاره د زیبکس کارول او دا به د MS SQL سرور څارنې ځینې اړخونه پوښي، په ځانګړې توګه: څنګه ژر تر ژره معلومه کړي چې کومې سرچینې ورکې دي، او همدارنګه د ټریس بیرغونو ترتیب کولو لپاره سپارښتنې.
د دې لپاره چې لاندې سکریپټونه کار وکړي، تاسو اړتیا لرئ چې په مطلوب ډیټابیس کې د انف سکیما په لاندې ډول جوړ کړئ:
د انف سکیما جوړول

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

په دې حالت کې، تاسو کولی شئ د لاندې پوښتنې سره د رام نشتوالی وټاکئ:

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.
د څارنې سیسټم ته د شاخصونو تولیدولو لپاره (د مثال په توګه، زبیکس)، تاسو کولی شئ لاندې دوه پوښتنې جوړې کړئ:

  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 سیسټم لید کارولو لپاره کافي دی. دلته، که چیرې د چلولو وړ_ټاسک_ شمیره په دوامداره توګه له 1 څخه زیاته وي، نو بیا ډیر احتمال شتون لري چې د کور شمیر د MS SQL سرور مثال لپاره کافي نه وي.
د څارنې سیسټم ته د شاخص تولیدولو لپاره (د مثال په توګه، زبیکس)، تاسو کولی شئ لاندې پوښتنه جوړه کړئ:

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

د دې شاخص لپاره د ترلاسه شوي ارزښتونو متحرکاتو پراساس ، موږ کولی شو دې پایلې ته ورسیږو چې ایا د MS SQL سرور مثال لپاره کافي پروسیسر وخت (د CPU کور شمیر) شتون لري.
په هرصورت، دا مهمه ده چې دا حقیقت په پام کې ونیسو چې پخپله غوښتنې کولی شي په یوځل کې د ډیری تارونو غوښتنه وکړي. او ځینې وختونه اصلاح کوونکی نشي کولی پخپله د پوښتنې پیچلتیا په سمه توګه اټکل کړي. بیا غوښتنه ممکن ډیری تارونه تخصیص شي چې په ورته وخت کې په ورته وخت کې پروسس نشي کیدی. او دا د پروسیسر وخت نشتوالي سره د یو ډول انتظار لامل هم کیږي ، او د مهالویش کونکو لپاره د قطار وده چې ځانګړي CPU کورونه کاروي ، د بیلګې په توګه د چلولو وړ_ټاسک_کاونټ شاخص به پدې شرایطو کې وده وکړي.
پدې حالت کې ، مخکې لدې چې د CPU کور شمیر زیات کړئ ، دا اړینه ده چې پخپله د MS SQL سرور مثال په سمه توګه موازي ملکیتونه تنظیم کړئ ، او د 2016 نسخه څخه ، د اړین ډیټابیسونو موازي ملکیتونه په سمه توګه تنظیم کړئ:
د MS SQL سرور څارنې ځینې اړخونه. د ټریس بیرغونو تنظیم کولو لپاره لارښوونې

د MS SQL سرور څارنې ځینې اړخونه. د ټریس بیرغونو تنظیم کولو لپاره لارښوونې
دلته تاسو باید لاندې پیرامیټونو ته پاملرنه وکړئ:

  1. د موازيتوب اعظمي درجې - د تارونو اعظمي شمیر ټاکي چې هرې غوښتنې ته تخصیص کیدی شي (ډیفالټ 0 دی - یوازې د عملیاتي سیسټم لخوا محدود دی او د MS SQL سرور نسخه)
  2. د موازي کولو لپاره د لګښت حد - د موازي اټکل اټکل شوی لګښت (ډیفالټ 5 دی)
  3. Max DOP - د تارونو اعظمي شمیر ټاکي چې د ډیټابیس په کچه هرې پوښتنې ته تخصیص کیدی شي (مګر د "متوازيتوب اعظمي درجې" ملکیت ارزښت څخه ډیر نه وي) (ډیفالټ 0 دی - یوازې د عملیاتي سیسټم لخوا محدود دی او د MS SQL سرور نسخه، په بیله بیا د MS SQL سرور د ټول مثال د "متوازيتوب اعظمي درجې" ملکیت باندې محدودیت)

دلته دا ناشونې ده چې د ټولو قضیو لپاره مساوي ښه ترکیب ورکړئ، د بیلګې په توګه تاسو د درنو پوښتنو تحلیل کولو ته اړتیا لرئ.
زما د خپلې تجربې څخه، زه د OLTP سیسټمونو لپاره د موازي ملکیتونو د تنظیم کولو لپاره د لاندې الګوریتم عمل وړاندیز کوم:

  1. لومړی موازي غیر فعال کړئ د مثال په اوږدو کې د موازي حد اعظمي درجې 1 ته په ترتیب کولو سره
  2. تر ټولو درانه غوښتنې تحلیل کړئ او د دوی لپاره د تارونو غوره شمیره وټاکئ
  3. د 2 مرحلې څخه ترلاسه شوي تریډونو غوره شمیر ته د موازيتوب اعظمي درجې تنظیم کړئ ، او د ځانګړي ډیټابیس لپاره د هر ډیټابیس لپاره د 2 مرحلې څخه ترلاسه شوي Max DOP ارزښت تنظیم کړئ
  4. تر ټولو درانه غوښتنې تحلیل کړئ او د ملټي ریډینګ منفي اغیزه وپیژنئ. که دا وي، نو د موازي کولو لپاره د لګښت حد زیات کړئ.
    د سیسټمونو لپاره لکه 1C، مایکروسافټ CRM او مایکروسافټ NAV، په ډیری قضیو کې، د ملټي ریډینګ منع کول مناسب دي

همچنان ، که چیرې معیاري نسخه شتون ولري ، نو په ډیری قضیو کې د ملټي ریډینګ منع کول د دې حقیقت له امله مناسب دي چې دا نسخه د CPU کورونو شمیر محدود دی.
د OLAP سیسټمونو لپاره، پورته تشریح شوي الګوریتم مناسب ندي.
زما د خپلې تجربې څخه، زه د OLAP سیسټمونو لپاره د موازي ملکیتونو تنظیم کولو لپاره د لاندې الګوریتم عمل وړاندیز کوم:

  1. تر ټولو درانه غوښتنې تحلیل کړئ او د دوی لپاره د تارونو غوره شمیره وټاکئ
  2. د 1 مرحلې څخه ترلاسه شوي تریډونو غوره شمیر ته د موازيتوب اعظمي درجې تنظیم کړئ ، او د ځانګړي ډیټابیس لپاره د هر ډیټابیس لپاره د 1 مرحلې څخه ترلاسه شوي Max DOP ارزښت تنظیم کړئ
  3. تر ټولو سختې پوښتنې تحلیل کړئ او د محدودیت د محدودیت منفي اغیز وپیژنئ. که دا وي، نو یا د موازي ارزښت لپاره د لګښت حد کم کړئ، یا د دې الګوریتم 1-2 مرحلې تکرار کړئ

دا دی، د OLTP سیسټمونو لپاره موږ د واحد-تریډینګ څخه څو-تریډینګ ته ځو، او د OLAP-سیسټمونو لپاره، په برعکس، موږ له څو-تریډینګ څخه واحد-تریډینګ ته ځو. په دې توګه، تاسو کولی شئ د یو ځانګړي ډیټابیس او د MS SQL سرور ټول مثال لپاره غوره موازي ترتیبات غوره کړئ.
دا هم پوهیدل مهم دي چې د موازي ملکیتونو ترتیبات باید د وخت په تیریدو سره بدل شي، د MS SQL سرور د فعالیت نظارت پایلو پراساس.

د ټریس بیرغونو تنظیم کولو لپاره لارښوونې

زما د خپلې تجربې او زما د همکارانو تجربې څخه، د غوره فعالیت لپاره، زه د 2008-2016 نسخو لپاره د MS SQL سرور خدمت د چلولو په کچه د لاندې ټریس بیرغونو تنظیم کولو وړاندیز کوم:

  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 تقسیم شوي حافظې توکي د CPU ویشل شوي شیانو ته بدلوي
  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 سرور احصایې انتظار وکړئ یا مهرباني وکړئ ما ته ووایاست چې دا چیرته درد کوي
» د سیسټم لید sys.dm_os_schedulers
» د MS SQL سرور ډیټابیس نظارت کولو لپاره د زیبکس کارول
» د SQL طرز ژوند
» بیرغونه تعقیب کړئ
» sql.ru

سرچینه: www.habr.com

Add a comment