WEBVTT

00:00:00.000 --> 00:00:10.500
[MUSICA].

00:00:10.500 --> 00:00:12.270
>> Ciao mi chiamo Pam,

00:00:12.270 --> 00:00:15.495
e io sono un Program Manager con
team di progettazione di SQL Server.

00:00:15.495 --> 00:00:17.790
Oggi mi piacerebbe fare
una rapida demo per voi

00:00:17.790 --> 00:00:19.800
su uno dei nuovi
funzionalità di SQL Server.

00:00:19.800 --> 00:00:23.310
2019 Ottimizzazione della memoria
Metadati TempDB.

00:00:23.310 --> 00:00:26.070
Ho già fatto un
video panoramica su

00:00:26.070 --> 00:00:27.480
questa funzione in cui
Parlo un po'

00:00:27.480 --> 00:00:29.040
su alcune delle sfide con

00:00:29.040 --> 00:00:32.295
prestazioni di TempDB
può aver affrontato in passato e

00:00:32.295 --> 00:00:35.850
sul lavoro che stiamo facendo nel 2019
per migliorare le prestazioni di TempDB.

00:00:35.850 --> 00:00:38.945
Quindi vi incoraggio a guardare che
video se non l'hai ancora visto.

00:00:38.945 --> 00:00:41.600
Cosa faremo
in questa demo oggi è

00:00:41.600 --> 00:00:45.185
concentrandosi sulla memoria ottimizzata
funzione dei metadati TempDB,

00:00:45.185 --> 00:00:46.805
come lo abiliti,

00:00:46.805 --> 00:00:47.975
come si sarebbe disattivarlo.

00:00:47.975 --> 00:00:49.640
Ma anche, come si può

00:00:49.640 --> 00:00:51.790
dire se è necessario
attivare questa funzione.

00:00:51.790 --> 00:00:55.600
Stai avendo il problema che
questa funzione è progettata per risolvere?

00:00:55.600 --> 00:00:58.770
Quindi cerchiamo di saltare nel
demo e dare un'occhiata.

00:01:00.220 --> 00:01:02.960
Così ho un taccuino aperto qui in

00:01:02.960 --> 00:01:05.420
Azure Data Studio
con alcuni comandi.

00:01:05.420 --> 00:01:09.050
Quello con cui inizieremo è correre
il carico di lavoro in SQL Server.

00:01:09.050 --> 00:01:14.315
2019 senza abilitare la memoria
Funzionalità dei metadati TempDB ottimizzatiOptimized TempDB metadata feature

00:01:14.315 --> 00:01:15.560
e cercheremo di dare un'occhiata a

00:01:15.560 --> 00:01:17.930
questa contesa che
può accadere in TempDB.

00:01:17.930 --> 00:01:21.050
Quindi la prima cosa che sto
intenzione di fare è iniziare

00:01:21.050 --> 00:01:24.170
un monitoraggio delle prestazioni
raccolta e raccolta

00:01:24.170 --> 00:01:26.120
un paio di diversi
contatori che darà

00:01:26.120 --> 00:01:28.430
noi un'idea del
prestazioni del carico di lavoro.

00:01:28.430 --> 00:01:31.955
Poi ho intenzione di utilizzare
lo strumento di sollecitazione O

00:01:31.955 --> 00:01:34.415
per eseguire un carico di lavoro multithreading.

00:01:34.415 --> 00:01:37.700
Così ho otto processori
su questa particolare macchina,

00:01:37.700 --> 00:01:39.950
ma sto lanciando 100
thread simultanei.

00:01:39.950 --> 00:01:42.350
Quindi ho un carico di lavoro molto occupato

00:01:42.350 --> 00:01:44.810
qui ed è molto
carico di lavoro TempDB pesante.

00:01:44.810 --> 00:01:47.210
Si tratta di una stored procedure di base
che crea una tabella temporanea,

00:01:47.210 --> 00:01:48.360
mettere alcuni dati in esso,

00:01:48.360 --> 00:01:49.805
e poi seleziona da esso.

00:01:49.805 --> 00:01:52.200
Così si può vedere qui in Perf uomo.

00:01:52.200 --> 00:01:54.090
Ho alcuni pesi in corso,

00:01:54.090 --> 00:01:55.740
i pesi del latch di pagina in corso.

00:01:55.740 --> 00:01:58.895
Ho anche il tempo medio di attesa

00:01:58.895 --> 00:02:00.380
elencati qui in Perf uomo pure.

00:02:00.380 --> 00:02:02.390
Così si può vedere che ho
pesi di latch di paging

00:02:02.390 --> 00:02:04.775
accade mentre sono
l'esecuzione di questo carico di lavoro.

00:02:04.775 --> 00:02:07.640
Questo non è insolito con un
carico di lavoro fortemente simultaneo.

00:02:07.640 --> 00:02:11.580
La domanda qui è: quali sono
questi pesi di latch di pagina da?

00:02:11.580 --> 00:02:12.770
Non lo sappiamo necessariamente.

00:02:12.770 --> 00:02:14.405
Potrebbero essere da
database utente.

00:02:14.405 --> 00:02:16.430
Potrebbero provengano da TempDB.

00:02:16.430 --> 00:02:18.740
In realtà non sappiamo solo
osservando le prestazioni

00:02:18.740 --> 00:02:21.620
monitorare dove questi latch di pagina
peschesono provenienti da.

00:02:21.620 --> 00:02:23.210
Quindi vogliamo tornare a

00:02:23.210 --> 00:02:25.850
Azure Data Studio e dare un'occhiata a

00:02:25.850 --> 00:02:27.110
uno script che può aiutarci

00:02:27.110 --> 00:02:30.880
determinare dove questi pagina
i pesi dei ganci provengono.

00:02:30.880 --> 00:02:32.230
Sembra che il mio carico di lavoro sia finito.

00:02:32.230 --> 00:02:34.190
Quindi sto solo andando a calci
indietro di nuovo in modo che noi

00:02:34.190 --> 00:02:36.925
È possibile osservare che Azure Data Studio.

00:02:36.925 --> 00:02:40.090
Quindi torniamo qui.

00:02:42.130 --> 00:02:47.135
Ho intenzione di eseguire questa query
che ho a fuoco.

00:02:47.135 --> 00:02:51.740
Ciò che questa query sta facendo è
guardando tutte le richieste da

00:02:51.740 --> 00:02:56.510
Richiesta esatta DM che ha
un tipo di peso come pagina,

00:02:56.510 --> 00:03:00.335
il che significa una sorta di
peso del latch di pagina.

00:03:00.335 --> 00:03:04.010
Quello che posso vedere nei risultati
ecco che ho effettivamente

00:03:04.010 --> 00:03:07.295
diverse sessioni che sono
in attesa sul latch di pagina.

00:03:07.295 --> 00:03:09.305
Se guardo la risorsa di peso,

00:03:09.305 --> 00:03:11.990
Posso dire solo dal peso
risorsa che sono in

00:03:11.990 --> 00:03:15.905
TempDB perché il peso
risorsa qui è 2:1:1:20.

00:03:15.905 --> 00:03:17.420
Due è l'ID del database,

00:03:17.420 --> 00:03:18.665
due che è TempDB.

00:03:18.665 --> 00:03:23.570
Uno è il file numero 1 e
allora 120 è il numero di pagina.

00:03:23.570 --> 00:03:25.325
Così posso dire che è in TempDB.

00:03:25.325 --> 00:03:30.395
Ma se uso questa nuova funzione
chiamata informazioni sulla pagina DMDB,

00:03:30.395 --> 00:03:34.039
ciò che questo mi permette di fare
è prendere quella risorsa pagina

00:03:34.039 --> 00:03:38.330
e rompere aperto e vedere
cosa c'è esattamente in quella pagina.

00:03:38.330 --> 00:03:41.355
Quindi, da quella funzione di info pagina DMDB,

00:03:41.355 --> 00:03:44.150
Ottengo questo oggetto
nome e si può vedere

00:03:44.150 --> 00:03:46.810
qui che il nome dell'oggetto
è un oggetto schema sys,

00:03:46.810 --> 00:03:48.095
che è una tabella di sistema.

00:03:48.095 --> 00:03:50.944
Quindi questo è che TempDB
contesa dei metadati

00:03:50.944 --> 00:03:52.685
di cui stavamo parlando.

00:03:52.685 --> 00:03:54.754
Questo è il problema

00:03:54.754 --> 00:03:58.220
che la memoria ottimizzata TempDB
metadati è stato introdotto per risolvere.

00:03:58.220 --> 00:03:59.960
Quindi torniamo a
nella finestra di comando.

00:03:59.960 --> 00:04:01.115
Possiamo vedere che è finita.

00:04:01.115 --> 00:04:02.450
Entrambe le volte che ha eseguito,

00:04:02.450 --> 00:04:06.005
ci sono voluti circa 52 secondi
per eseguire il carico di lavoro.

00:04:06.005 --> 00:04:09.675
Naturalmente possiamo vedere la pagina
peso del fermo accadendo.

00:04:09.675 --> 00:04:12.300
Possiamo vedere il lotto
richieste al secondo,

00:04:12.300 --> 00:04:14.100
che stanno saltando fuori a,

00:04:14.100 --> 00:04:18.225
vediamo qui, circa 350 massimo.

00:04:18.225 --> 00:04:20.210
Quindi questo è senza il
funzione attivata.

00:04:20.210 --> 00:04:22.265
Quindi andiamo avanti e
attivare la funzione.

00:04:22.265 --> 00:04:23.795
Per fare questo,

00:04:23.795 --> 00:04:25.925
abbiamo bisogno di abilitare la funzione in

00:04:25.925 --> 00:04:29.090
SQL Server e abbiamo anche bisogno
per riavviare il server.

00:04:29.090 --> 00:04:34.250
Questo alterare la configurazione del server
comando qui richiede un riavvio.

00:04:34.250 --> 00:04:38.875
Quindi stiamo andando a impostare quella memoria
Metadati TempDB ottimizzati attivati.

00:04:38.875 --> 00:04:43.540
Poi andrò avanti e
riavviare il server.

00:04:44.360 --> 00:04:48.025
Poi, una volta fatto questo,

00:04:48.025 --> 00:04:50.810
Sarò in grado di tornare

00:04:50.810 --> 00:04:54.155
Azure Data Studio e
eseguire un altro comando,

00:04:54.155 --> 00:04:57.470
selezionare la proprietà server
comando per vedere se

00:04:57.470 --> 00:05:01.160
l'ottimizzazione per la memoria TempDB
funzione di metadati è attivata.

00:05:01.160 --> 00:05:03.265
Quindi cerchiamo di eseguire questo comando.

00:05:03.265 --> 00:05:07.245
Si può vedere eseguito
e la funzione è ora accesa.

00:05:07.245 --> 00:05:10.565
È uno. Quindi andiamo avanti
ed eseguire di nuovo il nostro carico di lavoro.

00:05:10.565 --> 00:05:13.470
Iniziamo Perf man.

00:05:16.490 --> 00:05:19.350
Alviamo di nuovo il nostro carico di lavoro.

00:05:19.350 --> 00:05:20.775
Stessi carichi di lavoro esatti.

00:05:20.775 --> 00:05:24.130
Stessa stored procedure, 100 thread.

00:05:24.130 --> 00:05:27.080
Potresti notare qualcosa
diverso in Perf uomo subito.

00:05:27.080 --> 00:05:29.900
Prima di tutto, le richieste batch
al secondo è molto più alto.

00:05:29.900 --> 00:05:34.520
Stiamo salendo a oltre 500.

00:05:34.520 --> 00:05:36.320
Potrebbe anche andare un po' più in alto.

00:05:36.320 --> 00:05:37.580
Lascio che correre per un po' ,

00:05:37.580 --> 00:05:40.790
ma anche notare quelle pagine
i pesi dei ganci sono spariti.

00:05:40.790 --> 00:05:42.605
Niente più pesi di latch di pagina.

00:05:42.605 --> 00:05:45.740
Se torniamo ad Azure Data
Studio ed io eseguiamo questo comando

00:05:45.740 --> 00:05:48.990
guardare le sessioni.

00:05:48.990 --> 00:05:52.310
Si noti che non ci sono sessioni
che sono in attesa sul latch di pagina.

00:05:52.310 --> 00:05:55.865
Abbiamo completamente eliminato
i pesi di aggancio della pagina.

00:05:55.865 --> 00:05:57.590
Se torno a Perf man,

00:05:57.590 --> 00:06:00.005
già il mio carico di lavoro è finito.

00:06:00.005 --> 00:06:02.990
Così si può vedere che ho
miglioramento della produttività.

00:06:02.990 --> 00:06:05.675
Ho eliminato quelli
pesi di latch di pagina.

00:06:05.675 --> 00:06:07.580
Se scendo al mio carico di lavoro,

00:06:07.580 --> 00:06:10.130
è ora completato in 35 secondi

00:06:10.130 --> 00:06:13.760
contro i 52 secondi
senza la funzione attivata.

00:06:13.760 --> 00:06:19.220
Quindi questa caratteristica è progettata
per consentire di contribuire alla scalabilità

00:06:19.220 --> 00:06:23.240
il vostro pesante TempDB
carichi di lavoro controversi

00:06:23.240 --> 00:06:25.400
senza fare alcun
modifiche al codice.

00:06:25.400 --> 00:06:28.085
È sufficiente attivare la configurazione,

00:06:28.085 --> 00:06:31.640
riavviare il server e quindi
può essere immediatamente migliorato

00:06:31.640 --> 00:06:33.770
velocità effettiva e meno
pesi di latch di pagina

00:06:33.770 --> 00:06:36.320
carichi di lavoro contesi TempDB.

00:06:36.320 --> 00:06:38.300
Quindi spero che questo ti aiuti a imparare

00:06:38.300 --> 00:06:40.790
un po 'di più sul
funzione, come si dovrebbe usare,

00:06:40.790 --> 00:06:42.860
come si potrebbe sapere se
è necessario accenderlo

00:06:42.860 --> 00:06:45.020
o no e si ottiene un po 'di più

00:06:45.020 --> 00:06:46.970
entusiasti dei miglioramenti
che stanno arrivando

00:06:46.970 --> 00:06:49.610
SQL Server 2019 Grazie mille.

00:06:49.610 --> 00:07:04.210
[MUSICA]