WEBVTT

00:00:00.000 --> 00:00:01.830
>> SQL Server 2019 fornisce

00:00:01.830 --> 00:00:04.995
una nuova funzionalità per Linux chiamata
Buffer di log persistenti.

00:00:04.995 --> 00:00:06.960
Prima era disponibile per Windows,

00:00:06.960 --> 00:00:08.385
al giorno d'oggi anche su Linux,

00:00:08.385 --> 00:00:10.740
e ti aiuta ad eliminare
colli di bottiglia che potrebbero

00:00:10.740 --> 00:00:14.130
si verificano durante l'attesa di un registro
buffer due scaricamento su disco.

00:00:14.130 --> 00:00:18.300
Brian è qui per dirci tutto
su di esso oggi su Data Exposed.

00:00:18.300 --> 00:00:29.040
[MUSICA]

00:00:29.040 --> 00:00:32.115
>> Ciao, e benvenuto a un altro
episodio di Data Exposed.

00:00:32.115 --> 00:00:35.220
Sono il tuo ospite Jeroen, e
oggi ho Brian con me

00:00:35.220 --> 00:00:38.460
per parlare di Persistent
Buffer di log in SQL 2019.

00:00:38.460 --> 00:00:40.230
Salve, Brian, benvenuti allo spettacolo.

00:00:40.230 --> 00:00:42.195
>> Ciao, Jeroen. Grazie.

00:00:42.195 --> 00:00:46.045
>> Quindi cosa stiamo andando a parlare
su Persistent Long Buffers?

00:00:46.045 --> 00:00:47.160
>> Sì. Quindi...

00:00:47.160 --> 00:00:47.685
>> Che cos'è?

00:00:47.685 --> 00:00:50.400
>> Così Registro Persistente
Buffer è uno di ciò che

00:00:50.400 --> 00:00:53.325
chiamiamo l'In-Memory
Famiglia di funzionalità di database,

00:00:53.325 --> 00:00:55.965
che include OLTP in memoria,

00:00:55.965 --> 00:00:59.265
Buffer di registro persistente che
Dimostrerò oggi,

00:00:59.265 --> 00:01:01.845
a volte chiamato Tail di Log Caching,

00:01:01.845 --> 00:01:05.040
un file di dati e di registro
Illuminazione in Linux,

00:01:05.040 --> 00:01:07.470
Pool di buffer ibrido in
Linux e Windows,

00:01:07.470 --> 00:01:09.870
e Memoria-Ottimizzare i metadati TempDB.

00:01:09.870 --> 00:01:11.370
>> Ok. Bello.

00:01:11.370 --> 00:01:17.195
>> Quindi mi limiterò a menzionare rapidamente
sui dispositivi di memoria persistente.

00:01:17.195 --> 00:01:19.550
Un sacco di gente non ha
li ha visti, ma essenzialmente

00:01:19.550 --> 00:01:21.730
questi sono DIMM regolari che si

00:01:21.730 --> 00:01:26.275
l'infeednela nel tuo server che
hanno diverse capacità.

00:01:26.275 --> 00:01:30.545
MVDIMM-N che è un tipo di
tecnologia di memoria persistente,

00:01:30.545 --> 00:01:34.325
arriva un 8, 16 o 32
capacità DIMM gig,

00:01:34.325 --> 00:01:36.980
e poi l'ultima Intel ottenuta

00:01:36.980 --> 00:01:41.150
Memoria DC Persistente
capacità molto più elevate di un 128,

00:01:41.150 --> 00:01:44.810
256 gigabyte o 512 gigabyte DIMM.

00:01:44.810 --> 00:01:46.820
>> Questo è tutti loro
memoria persistente. Wow.

00:01:46.820 --> 00:01:48.060
>> Sì. Così si può,

00:01:48.060 --> 00:01:49.290
su un server socket nate,

00:01:49.290 --> 00:01:52.370
è possibile supportare fino a 24
terabyte di memoria persistente.

00:01:52.370 --> 00:01:53.750
>> Posso sbloccare tutti

00:01:53.750 --> 00:01:55.970
che con questo persistente
buffer di log, giusto?

00:01:55.970 --> 00:01:56.570
>> Corretto.

00:01:56.570 --> 00:01:57.680
>> Wow.

00:01:57.680 --> 00:02:00.110
>> Registro persistente
Buffer è progettato per

00:02:00.110 --> 00:02:02.075
risolvere un caso d'uso particolare

00:02:02.075 --> 00:02:07.400
dove si stavano incorrendo rallentamenti
o attende nel carico di lavoro,

00:02:07.400 --> 00:02:12.385
in attesa del buffer di registro che
è in memoria per scaricare su disco.

00:02:12.385 --> 00:02:13.005
>> Ok.

00:02:13.005 --> 00:02:16.114
>> Quindi utilizza il
dispositivo di memoria persistente

00:02:16.114 --> 00:02:19.355
su di esso sa che una volta che è
scritto su quel dispositivo,

00:02:19.355 --> 00:02:21.650
che non ha bisogno
di aspettare lo sciacquone

00:02:21.650 --> 00:02:24.270
perché è già in onda
un dispositivo persistente.

00:02:24.270 --> 00:02:26.195
>> Quindi il dispositivo sarà
prendersi cura del resto.

00:02:26.195 --> 00:02:28.835
>> Sì, il dispositivo
poi prendersi cura del resto

00:02:28.835 --> 00:02:31.730
mentre si continua essenzialmente
con il carico di lavoro.

00:02:31.730 --> 00:02:32.180
>> sì.

00:02:32.180 --> 00:02:35.585
>> Così, quando si sta impostando
questi dispositivi in Windows,

00:02:35.585 --> 00:02:41.600
abbiamo alcune raccomandazioni di base
che si bloccano le pagine in memoria,

00:02:41.600 --> 00:02:44.150
si utilizzano i due megabyte
dimensione dell'unità di allocazione

00:02:44.150 --> 00:02:46.760
PER NTFS che non sarà predefinito.

00:02:46.760 --> 00:02:47.180
>> Ok.

00:02:47.180 --> 00:02:49.715
>> Inoltre è necessario
impostare questo flag DAX.

00:02:49.715 --> 00:02:51.920
Quindi DAX è davvero ciò che ci permette di

00:02:51.920 --> 00:02:55.280
trattare una memoria persistente
dispositivo e scrivere su di esso

00:02:55.280 --> 00:02:57.260
direttamente saltando tutti

00:02:57.260 --> 00:02:59.795
lo stack del kernel che

00:02:59.795 --> 00:03:03.090
in genere si avrebbe bisogno
quando si tratta di file.

00:03:03.090 --> 00:03:05.145
Non sarà disponibile nella GUI,

00:03:05.145 --> 00:03:07.250
quindi è necessario utilizzare
alcuni PowerShell per questo.

00:03:07.250 --> 00:03:09.560
>> Ok. Va bene. Si sarà
mostraci come funziona, giusto?

00:03:09.560 --> 00:03:13.325
>> Sì. Vi mostrerò come
questi vengono configurati.

00:03:13.325 --> 00:03:16.430
Anche alcuni del tuo livello di sistema operativo
contatori del disco che si

00:03:16.430 --> 00:03:19.510
può essere abituato a guardare come
questi trasferimenti e così via,

00:03:19.510 --> 00:03:21.830
potrebbe non essere disponibile per

00:03:21.830 --> 00:03:24.200
quando si lavora con
dispositivi di memoria persistente.

00:03:24.200 --> 00:03:28.865
Questa è solo una delle cose
è necessario essere consapevoli.

00:03:28.865 --> 00:03:29.330
>> Certo.

00:03:29.330 --> 00:03:33.575
>> Questi sono nuovi dispositivi e questo
è molto nuovo di zecca virata emozionante.

00:03:33.575 --> 00:03:33.935
>> Ok.

00:03:33.935 --> 00:03:37.565
>> Quindi ci può essere qualche cattura
fino a fare sul lato del monitoraggio.

00:03:37.565 --> 00:03:38.245
>> Certo.

00:03:38.245 --> 00:03:42.580
>> Per Linux, non volatile
controllo del dispositivo

00:03:42.580 --> 00:03:45.110
è l'utilità che si
utilizzare per configurare questo.

00:03:45.110 --> 00:03:47.840
Si imposterà la modalità fsdax,

00:03:47.840 --> 00:03:50.795
utilizzare due enormi difetti di pagina megabyte,

00:03:50.795 --> 00:03:53.555
impostare l'allocazione dei blocchi
anche a due megabyte.

00:03:53.555 --> 00:03:56.180
Supportiamo XFS o EXT

00:03:56.180 --> 00:04:00.620
per questi sono due supportati
file system con DAX.

00:04:00.620 --> 00:04:01.295
>> Ok.

00:04:01.295 --> 00:04:03.050
>> Così Persistent Log Buffer,

00:04:03.050 --> 00:04:05.585
questo è stato disponibile
in realtà in SQL dal

00:04:05.585 --> 00:04:10.140
SQL 2016 solo per Windows fino ad ora.

00:04:10.140 --> 00:04:12.470
Con SQL 2019, avremo anche

00:04:12.470 --> 00:04:15.875
questa funzione è ora disponibile
in Linux e windows.

00:04:15.875 --> 00:04:18.590
Utilizza solo un piccolo
capacità,

00:04:18.590 --> 00:04:21.720
il buffer di registro è solo 20
megabyte per database utente.

00:04:21.720 --> 00:04:22.355
>> Ok.

00:04:22.355 --> 00:04:26.330
>> Quindi in realtà non ci vuole
una quantità enorme di capacità,

00:04:26.330 --> 00:04:28.850
e il comportamento che si ottiene è molto

00:04:28.850 --> 00:04:31.250
simile alla forzatura
durata ritardata.

00:04:31.250 --> 00:04:31.910
>> Ok.

00:04:31.910 --> 00:04:34.040
>> Quindi, ancora una volta, non stai aspettando

00:04:34.040 --> 00:04:36.890
che Log scaricamento per accadere su disco

00:04:36.890 --> 00:04:40.040
ma ha incoraggiato nessuno dei rischi che

00:04:40.040 --> 00:04:43.235
si prende ciò che forzato ritardato
Durata della perdita di dati.

00:04:43.235 --> 00:04:45.290
>> Così ci puoi dire un
po 'di più su

00:04:45.290 --> 00:04:47.550
Durabilità ritardata forzata
per coloro che sono...

00:04:47.550 --> 00:04:48.615
>> Certo, per coloro che...

00:04:48.615 --> 00:04:49.425
>> -non ne sono a conoscenza?

00:04:49.425 --> 00:04:52.095
>> Sì. Per coloro che
non sono familiari,

00:04:52.095 --> 00:04:53.840
questo è essenzialmente

00:04:53.840 --> 00:04:57.260
un commit asincrono
meccanismo in SQL Server.

00:04:57.260 --> 00:04:57.710
>> Ok.

00:04:57.710 --> 00:05:01.280
>> Quindi ci sono un paio
di modi per farlo.

00:05:01.280 --> 00:05:03.740
Uno è consentito, nel qual caso

00:05:03.740 --> 00:05:07.190
i tuoi commit normali
accadere come ci si aspetta,

00:05:07.190 --> 00:05:08.270
si aspetta lo sciacquone,

00:05:08.270 --> 00:05:10.455
attendere che siano induriti sul disco,

00:05:10.455 --> 00:05:15.440
o in una modalità forzata in cui tutti i
i commit si comportano in questo modo.

00:05:15.440 --> 00:05:16.000
>> Ok.

00:05:16.000 --> 00:05:19.220
>> Quindi, ciò che è permesso in
specificato in un

00:05:19.220 --> 00:05:22.880
commettere base se si desidera che questo
comportamento e questo è permesso,

00:05:22.880 --> 00:05:24.935
non consentito, ovvero l'impostazione predefinita

00:05:24.935 --> 00:05:27.425
non importa quello che hai in
lì non succederà.

00:05:27.425 --> 00:05:27.905
>> Certo.

00:05:27.905 --> 00:05:30.170
>> Poi costretto tutti
commit si comporta in questo modo.

00:05:30.170 --> 00:05:32.285
>> Ok. Quindi, in un persistente
basso livello è molto

00:05:32.285 --> 00:05:34.890
simile ma non del tutto lo stesso.

00:05:34.890 --> 00:05:37.215
>> Molto simile, ma
non del tutto la stessa cosa,

00:05:37.215 --> 00:05:39.845
perché abbiamo il
dispositivo di memoria persistente,

00:05:39.845 --> 00:05:42.965
abbiamo messo il nostro buffer di registro lì,

00:05:42.965 --> 00:05:46.640
e una volta che scriviamo lì sappiamo
che è persistente e noi

00:05:46.640 --> 00:05:50.360
non hanno alcun rischio di perdita di dati
in caso di arresto anomalo del server,

00:05:50.360 --> 00:05:53.000
interruzione dell'alimentazione, qualsiasi cosa
di quella natura,

00:05:53.000 --> 00:05:56.570
siamo in grado di recuperare dai dati su
dispositivo di memoria persistente.

00:05:56.570 --> 00:05:57.920
>> Ok. Bello.

00:05:57.920 --> 00:06:00.230
>> In realtà è abbastanza semplice.

00:06:00.230 --> 00:06:01.640
Molte persone non si rendono conto,

00:06:01.640 --> 00:06:04.355
è sufficiente aggiungere un file di registro

00:06:04.355 --> 00:06:07.580
di 20 megabyte sul
dispositivo di memoria persistente,

00:06:07.580 --> 00:06:10.370
SQL Server
riconoscere questo dispositivo,

00:06:10.370 --> 00:06:13.265
e lo tratterà come buffer di log.

00:06:13.265 --> 00:06:14.405
>> E 'molto semplice

00:06:14.405 --> 00:06:15.665
>> Davvero così semplice.

00:06:15.665 --> 00:06:16.205
>> Wow.

00:06:16.205 --> 00:06:19.550
>> sì, e come possiamo vedere
qui sono buffer di registro seduto su

00:06:19.550 --> 00:06:23.090
la nostra memoria di classe di memoria
che è PMM a volte

00:06:23.090 --> 00:06:26.480
lo chiamiamo classe di archiviazione
memoria e in alcuni luoghi

00:06:26.480 --> 00:06:30.405
ma la stessa cosa e la nostra
record di log sono lì,

00:06:30.405 --> 00:06:31.950
e, come ho detto,

00:06:31.950 --> 00:06:33.200
non dobbiamo aspettare
per loro attraverso

00:06:33.200 --> 00:06:36.365
lavato al principale
file di registro delle transazioni.

00:06:36.365 --> 00:06:37.010
>> Cool.

00:06:37.010 --> 00:06:41.875
>> Quindi mi limiterò a passare
rapidamente alla mia demo qui.

00:06:41.875 --> 00:06:42.990
>> sì.

00:06:42.990 --> 00:06:46.280
>> In primo luogo mi limiterò a mostrare
che abbiamo configurato

00:06:46.280 --> 00:06:49.310
qui i nostri dispositivi di memoria persistente.

00:06:49.310 --> 00:06:50.945
Come ho già detto, questi
sono DIMM regolari,

00:06:50.945 --> 00:06:53.180
è possibile visualizzare gli ID dispositivo.

00:06:53.180 --> 00:06:56.405
Abbiamo configurato due
dispositivi uno per ogni nodo NUMA.

00:06:56.405 --> 00:06:56.855
>> Ok.

00:06:56.855 --> 00:07:01.565
>> Interleaved tra i dispositivi
ai DIMM su quel nodo NUMA.

00:07:01.565 --> 00:07:05.330
Quindi questo è il raccomandato
modo che diciamo di impostare.

00:07:05.330 --> 00:07:06.410
>> Ok.

00:07:06.410 --> 00:07:08.950
>> Ancora una volta, possiamo vedere che

00:07:08.950 --> 00:07:12.920
il nostro valore DAX è abilitato
è impostato su true qui,

00:07:12.920 --> 00:07:17.464
e se vogliamo usare il nostro vecchio
utilità di tipo riga di comando,

00:07:17.464 --> 00:07:21.830
possiamo solo ottenere quel piccolo
po 'più informazioni qui e possiamo

00:07:21.830 --> 00:07:26.450
vedere che abbiamo impostato l'allocazione
dimensioni dell'unità fino a due megabyte.

00:07:26.450 --> 00:07:28.640
>> Come hai appena descritto.
Sì.

00:07:28.640 --> 00:07:31.505
>> sì. Come ho appena
descritto e abbastanza

00:07:31.505 --> 00:07:36.185
semplice abbiamo appena aggiungere il
log-file, come ho detto,

00:07:36.185 --> 00:07:38.205
e noi creiamo e

00:07:38.205 --> 00:07:40.700
indipendentemente dalla dimensione che
metterlo in qui faremo in realtà

00:07:40.700 --> 00:07:42.860
integrato per utilizzare 20 megabyte

00:07:42.860 --> 00:07:46.025
ma basta andare avanti e
diciamo 20 megabyte si siede.

00:07:46.025 --> 00:07:47.975
>> sì. Giusto per essere sicuri.

00:07:47.975 --> 00:07:50.960
>> Sì, ed è davvero così semplice.

00:07:50.960 --> 00:07:52.550
>> Wow. Va bene.

00:07:52.550 --> 00:07:54.200
Quindi è impressionante.

00:07:54.200 --> 00:07:56.900
Quindi in pratica posso sbloccare
tutte queste nuove tecnologie con

00:07:56.900 --> 00:07:58.580
un buffer di registro persistente

00:07:58.580 --> 00:08:00.650
esecuzione di comando molto semplice, giusto?

00:08:00.650 --> 00:08:01.055
>> sì.

00:08:01.055 --> 00:08:02.930
>> Certo. Devi
configurare prima il dispositivo,

00:08:02.930 --> 00:08:05.965
e poi dopo che è fatto
in SQL è sufficiente aggiungere un log.

00:08:05.965 --> 00:08:09.350
>> sì, e questo tipo

00:08:09.350 --> 00:08:12.725
della tecnologia è davvero
consentendo un nuovo livello di

00:08:12.725 --> 00:08:15.020
storage aiutando a rimuovere alcuni dei

00:08:15.020 --> 00:08:17.075
il tradizionale
strozzature che vediamo

00:08:17.075 --> 00:08:19.640
in SQL Server su carichi di lavoro di fascia alta.

00:08:19.640 --> 00:08:22.220
>> Destra. Così grande innovazione, ma

00:08:22.220 --> 00:08:24.710
poi fatto in modo molto semplice

00:08:24.710 --> 00:08:26.570
per l'utente e per
la configurazione.

00:08:26.570 --> 00:08:29.360
>> Sì. Costruiamo intelligenza
in SQL Server per

00:08:29.360 --> 00:08:32.240
riconoscere questi dispositivi
e comportarsi di conseguenza.

00:08:32.240 --> 00:08:34.295
>> sì. Molto figo. Bene
grazie per la condivisione.

00:08:34.295 --> 00:08:34.895
>> Grazie.

00:08:34.895 --> 00:08:36.560
>> Penso che questo è stato molto utile,

00:08:36.560 --> 00:08:37.910
molto interessante, almeno per me.

00:08:37.910 --> 00:08:40.490
Spero che questo sia stato utile e
interessante anche per voi.

00:08:40.490 --> 00:08:43.065
Si prega di iscriversi, come,
commentare il video,

00:08:43.065 --> 00:08:44.660
e spero di vederti la prossima volta su

00:08:44.660 --> 00:08:47.040
un altro episodio di
Dati esposti. Grazie.

00:08:47.040 --> 00:09:01.630
[MUSICA]

