ProHoster > Блог > Захиргаа > MS SQL серверийн мониторингийн зарим талууд. Trace Flags тохируулах заавар

MS SQL серверийн мониторингийн зарим талууд. Trace Flags тохируулах заавар

Өмнөх үг

MS SQL Server DBMS-ийн хэрэглэгчид, хөгжүүлэгчид болон администраторууд өгөгдлийн сан эсвэл бүхэлд нь DBMS-ийн гүйцэтгэлийн асуудалтай тулгардаг тул MS SQL Server-ийн хяналт нь маш их хамааралтай байдаг.
Энэ нийтлэл нь нийтлэлийн нэмэлт юм MS SQL серверийн мэдээллийн санг хянахын тулд Zabbix ашиглах мөн энэ нь MS SQL Server-ийн мониторингийн зарим талыг хамарна, тухайлбал: ямар нөөц байхгүй байгааг хэрхэн хурдан тодорхойлох, мөн ул мөрийн туг тохируулах зөвлөмжийг багтаана.
Дараах скриптүүдийг ажиллуулахын тулд та хүссэн мэдээллийн сандаа дараах байдлаар inf схем үүсгэх хэрэгтэй.
Inf схем үүсгэх

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

RAM-ийн дутагдлыг илрүүлэх арга

RAM дутагдалтай байгаагийн эхний үзүүлэлт бол MS SQL Server-ийн нэг хэсэг нь түүнд хуваарилагдсан бүх 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 Server-ийн жишээ нь түүнд хуваарилагдсан бүх санах ойг ашигладаг болохыг дараах асуулгаар тодорхойлж болно.

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

Хэрэв SQL_server_physical_memory_in_ua_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 Server жишээнд хангалттай RAM байхгүй байх магадлал маш өндөр байна. Систем бүрийн хувьд чухал утгыг тус тусад нь тодорхойлдог. Гэхдээ та дараахаас эхэлж болно: Хувь>=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 Server-ийн жишээнд хангалттай RAM байгаа эсэхийг бид дүгнэж болно.

CPU-ийн хэт ачааллыг илрүүлэх арга

Процессорын цаг хомс байгааг тодорхойлохын тулд sys.dm_os_schedulers системийн харагдацыг ашиглахад хангалттай. Энд, хэрэв ажиллуулж болох_даалгаврын_тоо байнга 1-ээс их байвал MS SQL Server жишээнд цөмийн тоо хангалтгүй байх магадлал өндөр байна.
Заагчийг хяналтын системд гаргахын тулд (жишээ нь, Zabbix) та дараах асуулга үүсгэж болно.

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

Энэ үзүүлэлтийн олж авсан утгуудын динамик дээр үндэслэн MS SQL Server-ийн жишээнд хангалттай процессорын хугацаа (CPU-ийн цөмийн тоо) байгаа эсэхийг бид дүгнэж болно.
Гэсэн хэдий ч, хүсэлт нь өөрөө нэг дор олон урсгалыг хүсэх боломжтой гэдгийг санах нь чухал юм. Заримдаа оновчлогч нь асуулгын нарийн төвөгтэй байдлыг зөв үнэлж чаддаггүй. Дараа нь хүсэлтийг өгөгдсөн хугацаанд нэгэн зэрэг боловсруулах боломжгүй хэт олон хэлхээг хуваарилж болно. Мөн энэ нь процессорын цаг дутмаг, тодорхой CPU цөм ашигладаг хуваарьлагчдын дараалал нэмэгдэхтэй холбоотой хүлээлтийн төрлийг үүсгэдэг, өөрөөр хэлбэл ийм нөхцөлд ажиллах боломжтой_даалгаврын_тоолох үзүүлэлт өсөх болно.
Энэ тохиолдолд CPU-ийн цөмийн тоог нэмэгдүүлэхийн өмнө MS SQL Server жишээний параллелизмын шинж чанарыг зөв тохируулах шаардлагатай бөгөөд 2016 оны хувилбараас шаардлагатай мэдээллийн сангийн параллелизм шинж чанарыг зөв тохируулах шаардлагатай.
MS SQL серверийн мониторингийн зарим талууд. Trace Flags тохируулах заавар

MS SQL серверийн мониторингийн зарим талууд. Trace Flags тохируулах заавар
Энд та дараах параметрүүдийг анхаарч үзэх хэрэгтэй.

  1. Зэрэгцээ байдлын хамгийн их зэрэг - хүсэлт бүрт хуваарилж болох урсгалын дээд хэмжээг тогтоодог (өгөгдмөл нь 0 - зөвхөн үйлдлийн систем өөрөө болон MS SQL Server-ийн хувилбараар хязгаарлагддаг)
  2. Зэрэгцээ байдлын зардлын босго - параллелизмын тооцоолсон зардал (өгөгдмөл нь 5)
  3. Max DOP - өгөгдлийн сангийн түвшинд асуулга бүрт хуваарилж болох хэлхээний дээд хэмжээг тогтоодог (гэхдээ "Зэрэгцээ байдлын дээд зэрэг" шинж чанарын утгаас ихгүй) (анхдагч нь 0 - зөвхөн үйлдлийн системээр хязгаарлагддаг ба MS SQL Server-ийн хувилбар, түүнчлэн MS SQL Server-ийн бүх жишээний "Зэрэгцээ байдлын дээд зэрэг" шинж чанарыг хязгаарлах)

Энд бүх тохиолдолд адил сайн жор өгөх боломжгүй, өөрөөр хэлбэл та хүнд асуултуудад дүн шинжилгээ хийх хэрэгтэй.
Би өөрийн туршлагаас харахад параллелизмын шинж чанарыг тохируулахын тулд OLTP системд зориулсан дараах үйлдлийн алгоритмыг санал болгож байна.

  1. эхлээд параллелизмын хамгийн их зэрэглэлийг 1 болгож тохируулж параллелизмыг идэвхгүй болгоно
  2. хамгийн хүнд хүсэлтийг задлан шинжилж, тэдгээрийн оновчтой тоог сонгох
  3. 2-р алхамаас олж авсан хэлхээний сонгосон оновчтой тоонд параллелизмын хамгийн их зэрэглэлийг тохируулах ба тодорхой мэдээллийн санд 2-р алхамаас авсан хамгийн их DOP утгыг мэдээллийн сан бүрд тохируулна.
  4. хамгийн хүнд хүсэлтүүдэд дүн шинжилгээ хийж, олон урсгалын сөрөг нөлөөг тодорхойлох. Хэрэв тийм бол Зэрэгцээ байдлын зардлын босгыг нэмэгдүүлнэ.
    1C, Microsoft CRM, Microsoft NAV зэрэг системүүдийн хувьд ихэнх тохиолдолд олон урсгалыг хориглох нь тохиромжтой байдаг.

Түүнчлэн, хэрэв Стандарт хувилбар байгаа бол ихэнх тохиолдолд энэ хэвлэл нь CPU-ийн цөмийн тоо хязгаарлагдмал байдаг тул олон урсгалыг хориглох нь тохиромжтой байдаг.
OLAP системүүдийн хувьд дээр дурдсан алгоритм тохиромжгүй.
Би өөрийн туршлагаас харахад параллелизмын шинж чанарыг тохируулахын тулд OLAP системд дараах үйлдлийн алгоритмыг санал болгож байна.

  1. хамгийн хүнд хүсэлтийг задлан шинжилж, тэдгээрийн оновчтой тоог сонгох
  2. 1-р алхамаас олж авсан хэлхээний сонгосон оновчтой тоонд параллелизмын хамгийн их зэрэглэлийг тохируулах ба тодорхой мэдээллийн санд 1-р алхамаас авсан хамгийн их DOP утгыг мэдээллийн сан бүрд тохируулна.
  3. хамгийн хүнд асуултуудад дүн шинжилгээ хийж, зэрэгцүүлэлтийг хязгаарлах сөрөг нөлөөг тодорхойлох. Хэрэв тийм бол Зэрэгцээ байдлын утгын зардлын босгыг бууруулж эсвэл энэ алгоритмын 1-2-р алхамуудыг давтана уу.

Өөрөөр хэлбэл, OLTP системүүдийн хувьд бид нэг урсгалтайгаас олон урсгалтай, OLAP системүүдийн хувьд эсрэгээрээ олон урсгалтайгаас нэг урсгалт руу шилждэг. Тиймээс та тодорхой мэдээллийн сан болон MS SQL Server-ийн бүх хувилбарт тохирох параллелизмын тохиргоог сонгох боломжтой.
MS SQL Server-ийн гүйцэтгэлийг хянах үр дүнд үндэслэн параллелизмын шинж чанаруудын тохиргоог цаг хугацааны явцад өөрчлөх шаардлагатай гэдгийг ойлгох нь чухал юм.

Trace Flags тохируулах заавар

Өөрийн туршлагаас болон хамтран ажиллагсдынхаа туршлагаас үндэслэн хамгийн оновчтой гүйцэтгэлийг хангахын тулд MS SQL Server үйлчилгээний 2008-2016 хувилбаруудын ажиллах түвшинд дараах ул мөрийг тохируулахыг зөвлөж байна.

  1. 610 - Индексжүүлсэн хүснэгтийн оруулгын бүртгэлийг багасгасан. WRITELOG нь индексийн өөрчлөлтийг байнга хүлээдэг, олон бүртгэл, олон гүйлгээ бүхий хүснэгтэд оруулахад тусалж чадна.
  2. 1117 - Хэрэв файлын бүлгийн файл автомат өсөлтийн босго шаардлагыг хангаж байвал файлын бүлгийн бүх файл өснө.
  3. 1118 - Бүх объектыг өөр өөр хэмжээнд байрлуулахыг албаддаг (холимог хүрээг хориглох), энэ нь холимог хүрээг хянахад ашигладаг SGAM хуудсыг скан хийх хэрэгцээг багасгадаг.
  4. 1224 - Түгжээний тооноос хамааран түгжээг нэмэгдүүлэхийг идэвхгүй болгоно. Гэсэн хэдий ч санах ойн хэт их хэрэглээ нь түгжээг нэмэгдүүлэхэд хүргэдэг
  5. 2371 - Статистикийн тогтмол автомат шинэчлэлтийн босгыг динамик автомат статистик шинэчлэлтийн босго болгон өөрчилдөг. Бүртгэлийн буруу тоо нь гүйцэтгэлийн төлөвлөгөөг буруу хийхэд хүргэдэг том хүснэгтүүдийн асуулгын төлөвлөгөөг шинэчлэхэд чухал ач холбогдолтой.
  6. 3226 - Алдааны бүртгэл дэх нөөцлөлтийн амжилтын мэдээг дарна
  7. 4199 - CUs болон SQL Server үйлчилгээний багцад гаргасан асуулга оновчтой болгох өөрчлөлтүүдийг багтаасан болно.
  8. 6532-6534 - Орон зайн өгөгдлийн төрлүүдийн асуулгад зориулсан гүйцэтгэлийн сайжруулалтыг багтаасан болно.
  9. 8048 - NUMA хуваалттай санах ойн объектуудыг CPU хуваалттай болгон хувиргана
  10. 8780 - Асуулга төлөвлөхөд нэмэлт цаг хуваарилахыг идэвхжүүлнэ. Энэ дарцаггүй зарим хүсэлтэд асуулгын төлөвлөгөө байхгүй тул татгалзаж болзошгүй (маш ховор алдаа)
  11. 8780 - 9389 - Багц горимын мэдэгдлийн нэмэлт динамик санах ойн буферийг идэвхжүүлдэг бөгөөд энэ нь багц горимын операторт илүү их санах ой хүсэх, хэрэв илүү их санах ой байгаа бол tempdb руу өгөгдлийг шилжүүлэхээс зайлсхийх боломжийг олгодог.

Мөн 2016 оноос өмнө 2301 ул мөрийг идэвхжүүлэх нь ашигтай бөгөөд энэ нь шийдвэрийн дэмжлэгийг оновчтой болгох боломжийг олгодог бөгөөд ингэснээр илүү зөв асуулгын төлөвлөгөөг сонгоход тусалдаг. Гэсэн хэдий ч 2016 оны хувилбарын хувьд энэ нь ихэвчлэн нэлээд урт асуулгын гүйцэтгэлийн хугацаанд сөрөг нөлөө үзүүлдэг.
Түүнчлэн, олон тооны индекстэй системүүдийн хувьд (жишээлбэл, 1С мэдээллийн сангийн хувьд) би индексийн ашиглалтын цуглуулгыг идэвхгүй болгодог trace flag 2330-г идэвхжүүлэхийг зөвлөж байна, энэ нь ерөнхийдөө системд эерэг нөлөө үзүүлдэг.
Ул мөр тугуудын талаар дэлгэрэнгүй мэдээллийг үзнэ үү энд
Дээрх холбоосоос MS SQL Server-ийн хувилбарууд болон бүтээцийг авч үзэх нь чухал бөгөөд шинэ хувилбаруудын хувьд зарим ул мөрийн тугуудыг анхдагчаар идэвхжүүлсэн эсвэл ямар ч нөлөө үзүүлэхгүй.
Та DBCC TRACEON болон DBCC TRACEOFF командын тусламжтайгаар ул мөрийн тугийг асааж, унтрааж болно. Дэлгэрэнгүй мэдээллийг үзнэ үү энд
Та DBCC TRACESTATUS командыг ашиглан ул мөрийн тугуудын статусыг авах боломжтой: дэлгэрэнгүй мэдээлэл
MS SQL серверийн үйлчилгээг автоматаар эхлүүлэхэд мөрийн тугуудыг оруулахын тулд та SQL серверийн тохиргооны менежер рүү очиж үйлчилгээний шинж чанарт -T-ээр дамжуулан эдгээр ул мөрийн тугуудыг нэмэх ёстой.
MS SQL серверийн мониторингийн зарим талууд. Trace Flags тохируулах заавар

Үр дүн

Энэ нийтлэлд MS SQL Server-ийг хянах зарим асуудлыг авч үзсэн бөгөөд үүний тусламжтайгаар та RAM дутагдал, CPU-ийн чөлөөт цаг, түүнчлэн бусад тодорхой бус асуудлуудыг хурдан тодорхойлох боломжтой болно. Хамгийн түгээмэл хэрэглэгддэг ул мөр тугуудыг хянаж үзсэн.

Эх сурвалж:

» SQL Server хүлээх статистик
» SQL Server статистикийг хүлээх эсвэл хаана өвдөж байгааг хэлж өгнө үү
» Системийн харагдац sys.dm_os_schedulers
» MS SQL серверийн мэдээллийн санг хянахын тулд Zabbix ашиглах
» SQL амьдралын хэв маяг
» Мөрний тугнууд
» sql.ru

Эх сурвалж: www.habr.com

сэтгэгдэл нэмэх