Rhai agweddau ar fonitro MS SQL Server. Canllawiau ar gyfer Gosod Baneri Hybrin

Rhagair

Yn aml iawn, mae defnyddwyr, datblygwyr a gweinyddwyr MS SQL Server DBMS yn wynebu problemau perfformiad y gronfa ddata neu'r DBMS yn ei gyfanrwydd, felly mae monitro Gweinyddwr MS SQL yn berthnasol iawn.
Mae'r erthygl hon yn ychwanegiad at yr erthygl Defnyddio Zabbix i Fonitro Cronfa Ddata Gweinyddwr MS SQL a bydd yn archwilio rhai agweddau ar fonitro MS SQL Server, yn arbennig: sut i benderfynu'n gyflym pa adnoddau sydd ar goll, yn ogystal ag argymhellion ar gyfer gosod baneri olrhain.
Er mwyn i'r sgriptiau canlynol weithio, mae angen i chi greu sgema inf yn y gronfa ddata a ddymunir fel a ganlyn:
Creu inf sgema

use <имя_Π‘Π”>;
go
create schema inf;

Dull o ganfod diffyg RAM

Y dangosydd cyntaf o ddiffyg RAM yw pan fydd enghraifft o MS SQL Server yn bwyta'r holl RAM a neilltuwyd iddo.
I wneud hyn, crΓ«wch y cynrychioliad canlynol inf.vRAM:
Creu'r golwg 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;

Yna gallwch chi benderfynu bod enghraifft o MS SQL Server yn defnyddio'r holl gof a neilltuwyd iddo gan ddefnyddio'r ymholiad canlynol:

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

Os yw'r dangosydd SQL_server_physical_memory_in_use_Mb yn gyson ddim yn llai na SQL_server_committed_target_Mb, yna mae angen i chi wirio'r ystadegau aros.
I bennu'r diffyg RAM trwy ystadegau aros, gadewch i ni greu golygfa inf.vWaits:
Creu'r olwg 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];

Yn yr achos hwn, gallwch chi benderfynu ar y diffyg RAM gan ddefnyddio'r ymholiad canlynol:

SELECT [Percentage]
      ,[AvgWait_S]
  FROM [inf].[vWaits]
  where [WaitType] in (
    'PAGEIOLATCH_XX',
    'RESOURCE_SEMAPHORE',
    'RESOURCE_SEMAPHORE_QUERY_COMPILE'
  );

Yma mae angen i chi dalu sylw i'r dangosyddion Canran ac AvgWait_S. Os ydynt yn arwyddocaol yn eu cyfanrwydd, yna mae tebygolrwydd uchel iawn nad oes gan yr enghraifft MS SQL Server ddigon o RAM. Pennir gwerthoedd hanfodol yn unigol ar gyfer pob system. Fodd bynnag, gallwch ddechrau gyda'r dangosydd canlynol: Canran>=1 ac AvgWait_S>=0.005.
I allbynnu dangosyddion i system fonitro (er enghraifft, Zabbix), gallwch greu'r ddau ymholiad canlynol:

  1. Beth yw canran y mathau o aros ar gyfer RAM (swm ar gyfer pob math o aros o'r fath):
    select coalesce(sum([Percentage]), 0.00) as [Percentage]
    from [inf].[vWaits]
           where [WaitType] in (
               'PAGEIOLATCH_XX',
               'RESOURCE_SEMAPHORE',
                'RESOURCE_SEMAPHORE_QUERY_COMPILE'
      );
    
  2. faint o fathau o aros RAM sy'n cymryd milieiliadau (gwerth uchaf yr holl oedi ar gyfartaledd ar gyfer pob math o aros o'r fath):
    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'
      );
    

Yn seiliedig ar ddeinameg y gwerthoedd a gafwyd ar gyfer y ddau ddangosydd hyn, gallwn ddod i'r casgliad a oes digon o RAM ar gyfer enghraifft MS SQL Server.

Dull ar gyfer canfod llwyth CPU gormodol

I nodi diffyg amser CPU, defnyddiwch y golwg system sys.dm_os_schedulers. Yma, os yw'r dangosydd runnable_tasks_count yn gyson yn fwy nag 1, yna mae tebygolrwydd uchel nad yw nifer y creiddiau yn ddigon ar gyfer enghraifft MS SQL Server.
I arddangos dangosydd mewn system fonitro (er enghraifft, Zabbix), gallwch greu'r cais canlynol:

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

Yn seiliedig ar ddeinameg y gwerthoedd a gafwyd ar gyfer y dangosydd hwn, gallwn ddod i'r casgliad a oes digon o amser prosesydd (nifer y creiddiau CPU) ar gyfer enghraifft MS SQL Server.
Fodd bynnag, mae'n bwysig cofio y gall yr ymholiadau eu hunain gwestiynu sawl trywydd ar unwaith. Ac weithiau ni all yr optimeiddiwr amcangyfrif cymhlethdod yr ymholiad ei hun yn gywir. Yna gellir dyrannu gormod o edafedd i'r cais, na ellir eu prosesu ar yr un pryd ar amser penodol. Ac mae hyn hefyd yn achosi math o aros sy'n gysylltiedig Γ’ diffyg amser prosesydd, a thwf y ciw ar gyfer amserlenwyr sy'n defnyddio creiddiau CPU penodol, hynny yw, bydd y dangosydd runnable_tasks_count yn cynyddu mewn amodau o'r fath.
Yn yr achos hwn, cyn cynyddu nifer y creiddiau CPU, mae angen i chi ffurfweddu priodweddau cyfochrog yr enghraifft MS SQL Server ei hun yn gywir, ac o fersiwn 2016, ffurfweddu priodweddau cyfochrog y cronfeydd data a ddymunir yn gywir:
Rhai agweddau ar fonitro MS SQL Server. Canllawiau ar gyfer Gosod Baneri Hybrin

Rhai agweddau ar fonitro MS SQL Server. Canllawiau ar gyfer Gosod Baneri Hybrin
Yma dylech roi sylw i'r paramedrau canlynol:

  1. Y Radd Uchaf o Baraleliaeth - yn gosod y nifer uchaf o edafedd y gellir eu dyrannu i bob cais (0 yw'r rhagosodiad - wedi'i gyfyngu gan y system weithredu ei hun a rhifyn MS SQL Server yn unig)
  2. Trothwy Costau ar gyfer Paraleliaeth - amcangyfrif o gost paraleliaeth (5 yw’r diofyn)
  3. Mae Max DOP - yn gosod y nifer uchaf o edafedd y gellir eu dyrannu i bob ymholiad ar lefel y gronfa ddata (ond dim mwy na gwerth yr eiddo "Uchaf Graddfa Barallelism") (yn ddiofyn mae'n 0 - wedi'i gyfyngu gan y system weithredu yn unig ei hun a'r argraffiad o MS SQL Server, yn ogystal Γ’ chyfyngiad ar yr eiddo β€œUchaf o Radd Cyfochrog” yr enghraifft MS SQL Server cyfan)

Mae'n amhosibl rhoi rysΓ‘it yr un mor dda ar gyfer pob achos, hynny yw, mae angen i chi ddadansoddi ymholiadau anodd.
Yn seiliedig ar fy mhrofiad fy hun, rwy'n argymell yr algorithm gweithredu canlynol ar gyfer systemau OLTP i ffurfweddu priodweddau cyfochrog:

  1. yn gyntaf analluoga paraleliaeth trwy osod Graddfa Baraleliaeth Uchaf i 1 ar lefel yr enghraifft gyfan
  2. dadansoddi'r ymholiadau trymaf a dewis y nifer optimaidd o edafedd ar eu cyfer
  3. gosod y Radd Uchaf o Baraleliaeth i'r nifer optimaidd dethol o edafedd a gafwyd o gam 2, a hefyd ar gyfer cronfeydd data penodol gosodwch y gwerth DOP Uchaf a gafwyd o gam 2 ar gyfer pob cronfa ddata
  4. dadansoddi'r ymholiadau trymaf a nodi effaith negyddol aml-edau. Os ydyw, yna cynyddwch y Trothwy Costau ar gyfer Parallelism.
    Ar gyfer systemau fel 1C, Microsoft CRM a Microsoft NAV, yn y rhan fwyaf o achosion mae gwahardd aml-edau yn addas

Hefyd, os oes gennych y rhifyn Safonol, yna yn y rhan fwyaf o achosion mae gwaharddiad ar aml-edau yn briodol oherwydd bod y rhifyn hwn yn gyfyngedig yn nifer y creiddiau CPU.
Nid yw'r algorithm a ddisgrifir uchod yn addas ar gyfer systemau OLAP.
Yn seiliedig ar fy mhrofiad fy hun, rwy'n argymell yr algorithm gweithredu canlynol ar gyfer systemau OLAP i ffurfweddu priodweddau cyfochrog:

  1. dadansoddi'r ymholiadau trymaf a dewis y nifer optimaidd o edafedd ar eu cyfer
  2. gosod y Radd Uchaf o Baraleliaeth i'r nifer optimaidd dethol o edafedd a gafwyd o gam 1, a hefyd ar gyfer cronfeydd data penodol gosodwch y gwerth DOP Uchaf a gafwyd o gam 1 ar gyfer pob cronfa ddata
  3. dadansoddi'r ymholiadau trymaf a nodi effaith negyddol cyfyngu ar arian cyfred. Os ydyw, yna naill ai gostwng y Trothwy Cost ar gyfer gwerth Parallelism, neu ailadrodd camau 1-2 yr algorithm hwn

Hynny yw, ar gyfer systemau OLTP rydym yn mynd o un edau i aml-edau, ac ar gyfer systemau OLAP, i'r gwrthwyneb, rydym yn mynd o aml-edau i edau sengl. Fel hyn gallwch ddewis y gosodiadau cyfochrog optimaidd ar gyfer cronfa ddata benodol ac ar gyfer yr enghraifft MS SQL Server gyfan.
Mae hefyd yn bwysig deall bod angen newid y gosodiadau eiddo concurrency dros amser, yn seiliedig ar ganlyniadau monitro perfformiad MS SQL Server.

Argymhellion ar gyfer gosod baneri hybrin

O'm profiad fy hun a phrofiad fy nghydweithwyr, ar gyfer y perfformiad gorau posibl, rwy'n argymell gosod y baneri olrhain canlynol ar lefel rhediad gwasanaeth MS SQL Server ar gyfer fersiynau 2008-2016:

  1. 610 - Lleihau logio mewnosodiadau mewn tablau mynegeio. Gall helpu gyda mewnosodiadau i dablau gyda nifer fawr o gofnodion a llawer o drafodion, gydag arosiadau YSGRIFENEDIG hir yn aml am newidiadau mewn mynegeion
  2. 1117 - Os yw ffeil mewn grΕ΅p ffeil yn cwrdd Γ’'r trothwy tyfu'n awtomatig, mae'r holl ffeiliau yn y grΕ΅p ffeiliau yn cael eu tyfu
  3. 1118 - Gorfodi'r holl wrthrychau i gael eu lleoli mewn gwahanol raddau (yn gwrthod meintiau cymysg), sy'n lleihau'r angen i sganio'r dudalen SGAM, a ddefnyddir i olrhain graddau cymysg
  4. 1224 - Yn analluogi codi cloeon yn seiliedig ar gyfrif clo. Fodd bynnag, gall defnydd gormodol o gof alluogi cynnydd clo
  5. 2371 - Yn newid y trothwy diweddaru ystadegau awtomatig sefydlog i'r trothwy diweddaru ystadegau awtomatig deinamig. Pwysig ar gyfer diweddaru cynlluniau ymholiad ar dablau mawr lle mae diffinio nifer y cofnodion yn anghywir yn arwain at gynlluniau gweithredu gwallus
  6. 3226 - Yn atal negeseuon llwyddiant wrth gefn yn y log gwallau
  7. 4199 - Yn cynnwys newidiadau i'r optimizer ymholiad a ryddhawyd mewn rholiau diweddaru SQL Server a phecynnau gwasanaeth
  8. 6532-6534 - Yn cynnwys gwelliannau perfformiad ar gyfer ymholiadau gyda mathau o ddata gofodol
  9. 8048 - Trosi gwrthrychau cof rhanedig NUMA i rai Γ’ rhaniad CPU
  10. 8780 - Galluogi neilltuo amser ychwanegol ar gyfer cynllunio ymholiadau. Efallai y bydd rhai ceisiadau heb y faner hon yn cael eu gwrthod oherwydd nad oes ganddynt gynllun ymholiad (gwall prin iawn)
  11. 8780 - 9389 - Galluogi byffer cof dros dro deinamig ychwanegol ar gyfer gweithredwyr modd swp, gan ganiatΓ‘u i weithredwr modd swp ofyn am gof ychwanegol ac osgoi trosglwyddo data i tempdb os oes cof ychwanegol ar gael

Mae hefyd yn ddefnyddiol galluogi olrhain baner 2016 cyn fersiwn 2301, sy'n galluogi optimeiddio cymorth penderfyniad uwch ac felly'n helpu i ddewis cynlluniau ymholiad gwell. Fodd bynnag, ers fersiwn 2016, mae'n aml yn cael effaith negyddol ar amseroedd gweithredu ymholiad cyffredinol eithaf hir.
Hefyd, ar gyfer systemau gyda llawer o fynegeion (er enghraifft, ar gyfer cronfeydd data 1C), rwy'n argymell galluogi olrhain baner 2330, sy'n analluogi casglu defnydd mynegai, sydd yn gyffredinol yn cael effaith gadarnhaol ar y system.
Gallwch ddysgu mwy am fflagiau olrhain yma
O'r ddolen uchod, mae hefyd yn bwysig ystyried fersiynau ac adeiladau MS SQL Server, oherwydd ar gyfer fersiynau mwy newydd, mae rhai fflagiau olrhain yn cael eu galluogi yn ddiofyn neu heb unrhyw effaith.
Gallwch chi alluogi neu analluogi'r faner olrhain gan ddefnyddio'r gorchmynion DBCC TRACEON a DBCC TRACEOFF, yn y drefn honno. Gweler mwy o fanylion yma
Gallwch gael statws baneri olrhain gan ddefnyddio'r gorchymyn DBCC TRACESTATUS: mwy
Er mwyn i fflagiau olrhain gael eu cynnwys yng nghychwyniad awtomatig gwasanaeth Gweinyddwr MS SQL, mae angen i chi fynd i Reolwr Ffurfweddu Gweinyddwr SQL ac ychwanegu'r fflagiau olrhain hyn trwy -T ym mhhriodweddau'r gwasanaeth:
Rhai agweddau ar fonitro MS SQL Server. Canllawiau ar gyfer Gosod Baneri Hybrin

Canlyniadau

Archwiliodd yr erthygl hon rai agweddau ar fonitro MS SQL Server, gyda chymorth y gallwch chi nodi'n gyflym ddiffyg RAM ac amser CPU rhad ac am ddim, yn ogystal Γ’ nifer o broblemau llai amlwg eraill. Adolygwyd y baneri olrhain a ddefnyddiwyd amlaf.

Ffynonellau:

Β» Ystadegau Aros Gweinydd SQL
Β» Ystadegau aros SQL Server neu dywedwch wrthyf ble mae'n brifo
Β» Gwedd system sys.dm_os_schedulers
Β» Defnyddio Zabbix i Fonitro Cronfa Ddata Gweinyddwr MS SQL
Β» Ffordd o Fyw SQL
Β» Olrhain baneri
Β» sql.ru

Ffynhonnell: hab.com

Ychwanegu sylw