โปรโฮสต์ > บล็อก > การบริหาร > ลักษณะบางอย่างของการตรวจสอบ MS SQL Server คำแนะนำสำหรับการตั้งค่าสถานะการติดตาม

ลักษณะบางอย่างของการตรวจสอบ MS SQL Server คำแนะนำสำหรับการตั้งค่าสถานะการติดตาม

คำปรารภ

บ่อยครั้งที่ผู้ใช้ นักพัฒนา และผู้ดูแลระบบ MS SQL Server DBMS ประสบปัญหาด้านประสิทธิภาพของฐานข้อมูลหรือ DBMS โดยรวม ดังนั้นการตรวจสอบ MS SQL Server จึงมีความเกี่ยวข้องมาก
บทความนี้เป็นส่วนเสริมของบทความ การใช้ Zabbix เพื่อตรวจสอบฐานข้อมูล MS SQL Server และจะตรวจสอบบางแง่มุมของการตรวจสอบ 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_use_Mb ไม่น้อยกว่า SQL_server_commission_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 หากมีความสำคัญในจำนวนทั้งสิ้น ก็มีโอกาสสูงมากที่อินสแตนซ์ 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'
  );

จากการเปลี่ยนแปลงของค่าที่ได้รับสำหรับตัวบ่งชี้ทั้งสองนี้ เราสามารถสรุปได้ว่ามี RAM เพียงพอสำหรับอินสแตนซ์ MS SQL Server หรือไม่

วิธีการตรวจจับโหลด CPU มากเกินไป

หากต้องการระบุการไม่มีเวลา CPU เพียงใช้มุมมองระบบ sys.dm_os_schedulers ที่นี่ หากตัวบ่งชี้ runnable_tasks_count มากกว่า 1 อย่างต่อเนื่อง แสดงว่ามีโอกาสสูงที่จำนวนคอร์จะไม่เพียงพอสำหรับอินสแตนซ์ MS SQL Server
หากต้องการแสดงตัวบ่งชี้ในระบบการตรวจสอบ (เช่น Zabbix) คุณสามารถสร้างคำขอต่อไปนี้:

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

จากการเปลี่ยนแปลงของค่าที่ได้รับสำหรับตัวบ่งชี้นี้ เราสามารถสรุปได้ว่ามีเวลาประมวลผลเพียงพอ (จำนวนแกน CPU) สำหรับอินสแตนซ์ MS SQL Server หรือไม่
อย่างไรก็ตาม สิ่งสำคัญคือต้องจำข้อเท็จจริงที่ว่าการสืบค้นสามารถสืบค้นหลายเธรดพร้อมกันได้ และบางครั้งเครื่องมือเพิ่มประสิทธิภาพไม่สามารถประมาณความซับซ้อนของแบบสอบถามได้อย่างถูกต้อง จากนั้นคำขออาจถูกจัดสรรเธรดมากเกินไป ซึ่งในเวลาที่กำหนดไม่สามารถประมวลผลพร้อมกันได้ และนี่ก็ทำให้เกิดการรอประเภทหนึ่งที่เกี่ยวข้องกับการไม่มีเวลาประมวลผลและการเติบโตของคิวสำหรับตัวกำหนดเวลาที่ใช้คอร์ CPU เฉพาะนั่นคือตัวบ่งชี้ runnable_tasks_count จะเพิ่มขึ้นในเงื่อนไขดังกล่าว
ในกรณีนี้ ก่อนที่จะเพิ่มจำนวนคอร์ CPU คุณต้องกำหนดค่าคุณสมบัติความขนานของอินสแตนซ์ MS SQL Server อย่างถูกต้อง และจากเวอร์ชัน 2016 ให้กำหนดค่าคุณสมบัติความขนานของฐานข้อมูลที่ต้องการอย่างถูกต้อง:
ลักษณะบางอย่างของการตรวจสอบ MS SQL Server คำแนะนำสำหรับการตั้งค่าสถานะการติดตาม

ลักษณะบางอย่างของการตรวจสอบ MS SQL Server คำแนะนำสำหรับการตั้งค่าสถานะการติดตาม
ที่นี่คุณควรใส่ใจกับพารามิเตอร์ต่อไปนี้:

  1. Max Degree of Parallelism—ตั้งค่าจำนวนเธรดสูงสุดที่สามารถจัดสรรให้กับแต่ละคำขอได้ (ค่าเริ่มต้นคือ 0—จำกัดโดยระบบปฏิบัติการและรุ่นของ MS SQL Server เท่านั้น)
  2. เกณฑ์ต้นทุนสำหรับความขนาน - ต้นทุนโดยประมาณของความขนาน (ค่าเริ่มต้นคือ 5)
  3. Max DOP—ตั้งค่าจำนวนเธรดสูงสุดที่สามารถจัดสรรให้กับแต่ละการสืบค้นในระดับฐานข้อมูล (แต่ไม่เกินค่าของคุณสมบัติ “Max Degree of Parallelism”) (โดยค่าเริ่มต้นคือ 0—จำกัดโดยระบบปฏิบัติการเท่านั้น ตัวมันเองและรุ่นของ MS SQL Server รวมถึงข้อจำกัดเกี่ยวกับคุณสมบัติ “Max Degree of Parallelism” ของอินสแตนซ์ MS SQL Server ทั้งหมด)

เป็นไปไม่ได้ที่จะให้สูตรที่ดีเท่ากันในทุกกรณีนั่นคือคุณต้องวิเคราะห์คำถามที่ยาก
จากประสบการณ์ของฉันเอง ฉันขอแนะนำอัลกอริธึมการดำเนินการต่อไปนี้สำหรับระบบ OLTP เพื่อกำหนดค่าคุณสมบัติความขนาน:

  1. ขั้นแรกให้ปิดการใช้งานความขนานโดยตั้งค่า Max Degree of Parallelism เป็น 1 ที่ระดับของอินสแตนซ์ทั้งหมด
  2. วิเคราะห์ข้อความค้นหาที่หนักที่สุดและเลือกจำนวนเธรดที่เหมาะสมที่สุด
  3. ตั้งค่า Max Degree of Parallelism เป็นจำนวนเธรดที่เหมาะสมที่สุดที่เลือกซึ่งได้รับจากขั้นตอนที่ 2 และสำหรับฐานข้อมูลเฉพาะให้ตั้งค่า Max DOP ที่ได้รับจากขั้นตอนที่ 2 สำหรับแต่ละฐานข้อมูล
  4. วิเคราะห์คำถามที่หนักที่สุดและระบุผลเสียของมัลติเธรด หากเป็นเช่นนั้น ให้เพิ่มเกณฑ์ต้นทุนสำหรับการทำงานแบบขนาน
    สำหรับระบบเช่น 1C, Microsoft CRM และ Microsoft NAV ในกรณีส่วนใหญ่การห้ามใช้มัลติเธรดนั้นเหมาะสม

นอกจากนี้ หากคุณมีรุ่น Standard ในกรณีส่วนใหญ่ การห้ามใช้มัลติเธรดก็เหมาะสม เนื่องจากรุ่นนี้มีจำนวนคอร์ CPU ที่จำกัด
อัลกอริทึมที่อธิบายไว้ข้างต้นไม่เหมาะสำหรับระบบ OLAP
จากประสบการณ์ของฉันเอง ฉันขอแนะนำอัลกอริธึมการดำเนินการต่อไปนี้สำหรับระบบ OLAP เพื่อกำหนดค่าคุณสมบัติความขนาน:

  1. วิเคราะห์ข้อความค้นหาที่หนักที่สุดและเลือกจำนวนเธรดที่เหมาะสมที่สุด
  2. ตั้งค่า Max Degree of Parallelism เป็นจำนวนเธรดที่เหมาะสมที่สุดที่เลือกซึ่งได้รับจากขั้นตอนที่ 1 และสำหรับฐานข้อมูลเฉพาะให้ตั้งค่า Max DOP ที่ได้รับจากขั้นตอนที่ 1 สำหรับแต่ละฐานข้อมูล
  3. วิเคราะห์คำถามที่หนักที่สุดและระบุผลเสียของการจำกัดการทำงานพร้อมกัน หากเป็นเช่นนั้น ให้ลดเกณฑ์ต้นทุนสำหรับค่า Parallelism หรือทำซ้ำขั้นตอนที่ 1-2 ของอัลกอริทึมนี้

นั่นคือ สำหรับระบบ OLTP เราไปจากเธรดเดี่ยวไปเป็นมัลติเธรด และสำหรับระบบ OLAP ตรงกันข้าม เราไปจากมัลติเธรดไปเป็นเธรดเดี่ยว วิธีนี้ทำให้คุณสามารถเลือกการตั้งค่าความขนานที่เหมาะสมที่สุดทั้งสำหรับฐานข้อมูลเฉพาะและสำหรับอินสแตนซ์ MS SQL Server ทั้งหมด
สิ่งสำคัญคือต้องเข้าใจว่าจำเป็นต้องเปลี่ยนการตั้งค่าคุณสมบัติการทำงานพร้อมกันเมื่อเวลาผ่านไป โดยขึ้นอยู่กับผลลัพธ์ของการตรวจสอบประสิทธิภาพของ MS SQL Server

คำแนะนำสำหรับการตั้งค่าแฟล็กการติดตาม

จากประสบการณ์ของฉันและเพื่อนร่วมงานของฉัน เพื่อประสิทธิภาพสูงสุด ฉันขอแนะนำให้ตั้งค่าสถานะการติดตามต่อไปนี้ที่ระดับการทำงานของบริการ MS SQL Server สำหรับเวอร์ชัน 2008-2016:

  1. 610 - ลดการบันทึกส่วนแทรกลงในตารางที่จัดทำดัชนี สามารถช่วยในการแทรกลงในตารางที่มีบันทึกจำนวนมากและธุรกรรมจำนวนมากโดยที่ WRITELOG ยาวนานบ่อยครั้งจะรอการเปลี่ยนแปลงในดัชนี
  2. 1117 - หากไฟล์ในกลุ่มไฟล์ตรงตามเกณฑ์การเติบโตอัตโนมัติ ไฟล์ทั้งหมดในกลุ่มไฟล์จะขยายใหญ่ขึ้น
  3. 1118 - บังคับให้วัตถุทั้งหมดอยู่ในขอบเขตที่แตกต่างกัน (ไม่อนุญาตให้มีขอบเขตแบบผสม) ซึ่งช่วยลดความจำเป็นในการสแกนหน้า SGAM ซึ่งใช้ในการติดตามขอบเขตแบบผสม
  4. 1224 - ปิดใช้งานการเลื่อนระดับการล็อคตามจำนวนการล็อค อย่างไรก็ตาม การใช้หน่วยความจำมากเกินไปสามารถเปิดใช้งานการเลื่อนระดับการล็อกได้
  5. 2371 - เปลี่ยนเกณฑ์การอัปเดตสถิติอัตโนมัติแบบคงที่เป็นเกณฑ์การอัปเดตสถิติอัตโนมัติแบบไดนามิก สิ่งสำคัญสำหรับการอัปเดตแผนการสืบค้นบนตารางขนาดใหญ่ ซึ่งการกำหนดจำนวนระเบียนไม่ถูกต้องส่งผลให้เกิดแผนการดำเนินการที่ผิดพลาด
  6. 3226 - ระงับข้อความแสดงความสำเร็จในการสำรองข้อมูลในบันทึกข้อผิดพลาด
  7. 4199 - รวมการเปลี่ยนแปลงเครื่องมือเพิ่มประสิทธิภาพแบบสอบถามที่เผยแพร่ในการยกเลิกการอัปเดต SQL Server และ Service Pack
  8. 6532-6534 - รวมการปรับปรุงประสิทธิภาพสำหรับการสืบค้นด้วยประเภทข้อมูลเชิงพื้นที่
  9. 8048 - แปลงวัตถุหน่วยความจำที่แบ่งพาร์ติชัน NUMA เป็นวัตถุที่แบ่งพาร์ติชัน CPU
  10. 8780 - เปิดใช้งานการจัดสรรเวลาเพิ่มเติมสำหรับการวางแผนแบบสอบถาม คำขอบางรายการที่ไม่มีแฟล็กนี้อาจถูกปฏิเสธเนื่องจากไม่มีแผนการสืบค้น (ข้อผิดพลาดที่หายากมาก)
  11. 8780 - 9389 - เปิดใช้งานบัฟเฟอร์หน่วยความจำชั่วคราวแบบไดนามิกเพิ่มเติมสำหรับตัวดำเนินการโหมดแบตช์ ช่วยให้ตัวดำเนินการโหมดแบตช์สามารถขอหน่วยความจำเพิ่มเติม และหลีกเลี่ยงการถ่ายโอนข้อมูลไปยัง tempdb หากมีหน่วยความจำเพิ่มเติม

นอกจากนี้ ยังมีประโยชน์ในการเปิดใช้งานแฟล็กการติดตาม 2016 ก่อนเวอร์ชัน 2301 ซึ่งเปิดใช้งานการปรับให้เหมาะสมสนับสนุนการตัดสินใจขั้นสูง และช่วยในการเลือกแผนการสืบค้นที่ดีขึ้น อย่างไรก็ตาม ตั้งแต่เวอร์ชัน 2016 มักส่งผลเสียต่อเวลาดำเนินการคิวรีโดยรวมที่ค่อนข้างยาวนาน
นอกจากนี้ สำหรับระบบที่มีดัชนีจำนวนมาก (เช่น สำหรับฐานข้อมูล 1C) ฉันแนะนำให้เปิดใช้งานแฟล็กการติดตาม 2330 ซึ่งจะปิดใช้งานการรวบรวมการใช้ดัชนี ซึ่งโดยทั่วไปจะมีผลเชิงบวกต่อระบบ
คุณสามารถเรียนรู้เพิ่มเติมเกี่ยวกับแฟล็กการติดตาม ที่นี่
จากลิงก์ด้านบน การพิจารณาเวอร์ชันและบิลด์ของ MS SQL Server ก็เป็นสิ่งสำคัญเช่นกัน สำหรับเวอร์ชันที่ใหม่กว่า ค่าสถานะการติดตามบางส่วนจะเปิดใช้งานตามค่าเริ่มต้นหรือไม่มีผลใดๆ
คุณสามารถเปิดใช้งานหรือปิดใช้งานแฟล็กการติดตามได้โดยใช้คำสั่ง DBCC TRACEON และ DBCC TRACEOFF ตามลำดับ ดูรายละเอียดเพิ่มเติม ที่นี่
คุณสามารถรับสถานะของแฟล็กการติดตามได้โดยใช้คำสั่ง DBCC TRACESTATUS: ขึ้น
เพื่อให้แฟล็กการติดตามถูกรวมไว้ในการเริ่มต้นอัตโนมัติของบริการ MS SQL Server คุณต้องไปที่ SQL Server Configuration Manager และเพิ่มแฟล็กการติดตามเหล่านี้ผ่าน -T ในคุณสมบัติของบริการ:
ลักษณะบางอย่างของการตรวจสอบ MS SQL Server คำแนะนำสำหรับการตั้งค่าสถานะการติดตาม

ผลของการ

บทความนี้จะตรวจสอบบางแง่มุมของการตรวจสอบ MS SQL Server ด้วยความช่วยเหลือซึ่งคุณสามารถระบุการขาด RAM และเวลา CPU ว่างได้อย่างรวดเร็ว รวมถึงปัญหาอื่น ๆ ที่ไม่ชัดเจนอื่น ๆ อีกจำนวนหนึ่ง มีการตรวจสอบแฟล็กการติดตามที่ใช้บ่อยที่สุด

แหล่งที่มา:

» สถิติการรอของเซิร์ฟเวอร์ SQL
» สถิติการรอ SQL Server หรือกรุณาบอกฉันว่ามันเจ็บตรงไหน
» มุมมองระบบ sys.dm_os_schedulers
» การใช้ Zabbix เพื่อตรวจสอบฐานข้อมูล MS SQL Server
» ไลฟ์สไตล์ SQL
» ติดตามธง
» sql.ru

ที่มา: will.com

เพิ่มความคิดเห็น