คำปรารภ
บ่อยครั้งที่ผู้ใช้ นักพัฒนา และผู้ดูแลระบบ MS SQL Server DBMS ประสบปัญหาด้านประสิทธิภาพของฐานข้อมูลหรือ DBMS โดยรวม ดังนั้นการตรวจสอบ 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) คุณสามารถสร้างแบบสอบถามสองรายการต่อไปนี้:
- เปอร์เซ็นต์ของประเภทการรอสำหรับ 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' );
จากการเปลี่ยนแปลงของค่าที่ได้รับสำหรับตัวบ่งชี้ทั้งสองนี้ เราสามารถสรุปได้ว่ามี 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 ให้กำหนดค่าคุณสมบัติความขนานของฐานข้อมูลที่ต้องการอย่างถูกต้อง:
ที่นี่คุณควรใส่ใจกับพารามิเตอร์ต่อไปนี้:
- Max Degree of Parallelism—ตั้งค่าจำนวนเธรดสูงสุดที่สามารถจัดสรรให้กับแต่ละคำขอได้ (ค่าเริ่มต้นคือ 0—จำกัดโดยระบบปฏิบัติการและรุ่นของ MS SQL Server เท่านั้น)
- เกณฑ์ต้นทุนสำหรับความขนาน - ต้นทุนโดยประมาณของความขนาน (ค่าเริ่มต้นคือ 5)
- Max DOP—ตั้งค่าจำนวนเธรดสูงสุดที่สามารถจัดสรรให้กับแต่ละการสืบค้นในระดับฐานข้อมูล (แต่ไม่เกินค่าของคุณสมบัติ “Max Degree of Parallelism”) (โดยค่าเริ่มต้นคือ 0—จำกัดโดยระบบปฏิบัติการเท่านั้น ตัวมันเองและรุ่นของ MS SQL Server รวมถึงข้อจำกัดเกี่ยวกับคุณสมบัติ “Max Degree of Parallelism” ของอินสแตนซ์ MS SQL Server ทั้งหมด)
เป็นไปไม่ได้ที่จะให้สูตรที่ดีเท่ากันในทุกกรณีนั่นคือคุณต้องวิเคราะห์คำถามที่ยาก
จากประสบการณ์ของฉันเอง ฉันขอแนะนำอัลกอริธึมการดำเนินการต่อไปนี้สำหรับระบบ OLTP เพื่อกำหนดค่าคุณสมบัติความขนาน:
- ขั้นแรกให้ปิดการใช้งานความขนานโดยตั้งค่า Max Degree of Parallelism เป็น 1 ที่ระดับของอินสแตนซ์ทั้งหมด
- วิเคราะห์ข้อความค้นหาที่หนักที่สุดและเลือกจำนวนเธรดที่เหมาะสมที่สุด
- ตั้งค่า Max Degree of Parallelism เป็นจำนวนเธรดที่เหมาะสมที่สุดที่เลือกซึ่งได้รับจากขั้นตอนที่ 2 และสำหรับฐานข้อมูลเฉพาะให้ตั้งค่า Max DOP ที่ได้รับจากขั้นตอนที่ 2 สำหรับแต่ละฐานข้อมูล
- วิเคราะห์คำถามที่หนักที่สุดและระบุผลเสียของมัลติเธรด หากเป็นเช่นนั้น ให้เพิ่มเกณฑ์ต้นทุนสำหรับการทำงานแบบขนาน
สำหรับระบบเช่น 1C, Microsoft CRM และ Microsoft NAV ในกรณีส่วนใหญ่การห้ามใช้มัลติเธรดนั้นเหมาะสม
นอกจากนี้ หากคุณมีรุ่น Standard ในกรณีส่วนใหญ่ การห้ามใช้มัลติเธรดก็เหมาะสม เนื่องจากรุ่นนี้มีจำนวนคอร์ CPU ที่จำกัด
อัลกอริทึมที่อธิบายไว้ข้างต้นไม่เหมาะสำหรับระบบ OLAP
จากประสบการณ์ของฉันเอง ฉันขอแนะนำอัลกอริธึมการดำเนินการต่อไปนี้สำหรับระบบ OLAP เพื่อกำหนดค่าคุณสมบัติความขนาน:
- วิเคราะห์ข้อความค้นหาที่หนักที่สุดและเลือกจำนวนเธรดที่เหมาะสมที่สุด
- ตั้งค่า Max Degree of Parallelism เป็นจำนวนเธรดที่เหมาะสมที่สุดที่เลือกซึ่งได้รับจากขั้นตอนที่ 1 และสำหรับฐานข้อมูลเฉพาะให้ตั้งค่า Max DOP ที่ได้รับจากขั้นตอนที่ 1 สำหรับแต่ละฐานข้อมูล
- วิเคราะห์คำถามที่หนักที่สุดและระบุผลเสียของการจำกัดการทำงานพร้อมกัน หากเป็นเช่นนั้น ให้ลดเกณฑ์ต้นทุนสำหรับค่า Parallelism หรือทำซ้ำขั้นตอนที่ 1-2 ของอัลกอริทึมนี้
นั่นคือ สำหรับระบบ OLTP เราไปจากเธรดเดี่ยวไปเป็นมัลติเธรด และสำหรับระบบ OLAP ตรงกันข้าม เราไปจากมัลติเธรดไปเป็นเธรดเดี่ยว วิธีนี้ทำให้คุณสามารถเลือกการตั้งค่าความขนานที่เหมาะสมที่สุดทั้งสำหรับฐานข้อมูลเฉพาะและสำหรับอินสแตนซ์ MS SQL Server ทั้งหมด
สิ่งสำคัญคือต้องเข้าใจว่าจำเป็นต้องเปลี่ยนการตั้งค่าคุณสมบัติการทำงานพร้อมกันเมื่อเวลาผ่านไป โดยขึ้นอยู่กับผลลัพธ์ของการตรวจสอบประสิทธิภาพของ MS SQL Server
คำแนะนำสำหรับการตั้งค่าแฟล็กการติดตาม
จากประสบการณ์ของฉันและเพื่อนร่วมงานของฉัน เพื่อประสิทธิภาพสูงสุด ฉันขอแนะนำให้ตั้งค่าสถานะการติดตามต่อไปนี้ที่ระดับการทำงานของบริการ MS SQL Server สำหรับเวอร์ชัน 2008-2016:
- 610 - ลดการบันทึกส่วนแทรกลงในตารางที่จัดทำดัชนี สามารถช่วยในการแทรกลงในตารางที่มีบันทึกจำนวนมากและธุรกรรมจำนวนมากโดยที่ WRITELOG ยาวนานบ่อยครั้งจะรอการเปลี่ยนแปลงในดัชนี
- 1117 - หากไฟล์ในกลุ่มไฟล์ตรงตามเกณฑ์การเติบโตอัตโนมัติ ไฟล์ทั้งหมดในกลุ่มไฟล์จะขยายใหญ่ขึ้น
- 1118 - บังคับให้วัตถุทั้งหมดอยู่ในขอบเขตที่แตกต่างกัน (ไม่อนุญาตให้มีขอบเขตแบบผสม) ซึ่งช่วยลดความจำเป็นในการสแกนหน้า SGAM ซึ่งใช้ในการติดตามขอบเขตแบบผสม
- 1224 - ปิดใช้งานการเลื่อนระดับการล็อคตามจำนวนการล็อค อย่างไรก็ตาม การใช้หน่วยความจำมากเกินไปสามารถเปิดใช้งานการเลื่อนระดับการล็อกได้
- 2371 - เปลี่ยนเกณฑ์การอัปเดตสถิติอัตโนมัติแบบคงที่เป็นเกณฑ์การอัปเดตสถิติอัตโนมัติแบบไดนามิก สิ่งสำคัญสำหรับการอัปเดตแผนการสืบค้นบนตารางขนาดใหญ่ ซึ่งการกำหนดจำนวนระเบียนไม่ถูกต้องส่งผลให้เกิดแผนการดำเนินการที่ผิดพลาด
- 3226 - ระงับข้อความแสดงความสำเร็จในการสำรองข้อมูลในบันทึกข้อผิดพลาด
- 4199 - รวมการเปลี่ยนแปลงเครื่องมือเพิ่มประสิทธิภาพแบบสอบถามที่เผยแพร่ในการยกเลิกการอัปเดต SQL Server และ Service Pack
- 6532-6534 - รวมการปรับปรุงประสิทธิภาพสำหรับการสืบค้นด้วยประเภทข้อมูลเชิงพื้นที่
- 8048 - แปลงวัตถุหน่วยความจำที่แบ่งพาร์ติชัน NUMA เป็นวัตถุที่แบ่งพาร์ติชัน CPU
- 8780 - เปิดใช้งานการจัดสรรเวลาเพิ่มเติมสำหรับการวางแผนแบบสอบถาม คำขอบางรายการที่ไม่มีแฟล็กนี้อาจถูกปฏิเสธเนื่องจากไม่มีแผนการสืบค้น (ข้อผิดพลาดที่หายากมาก)
- 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 ด้วยความช่วยเหลือซึ่งคุณสามารถระบุการขาด RAM และเวลา CPU ว่างได้อย่างรวดเร็ว รวมถึงปัญหาอื่น ๆ ที่ไม่ชัดเจนอื่น ๆ อีกจำนวนหนึ่ง มีการตรวจสอบแฟล็กการติดตามที่ใช้บ่อยที่สุด
แหล่งที่มา:
»
»
»
»
»
»
»
ที่มา: will.com