WEBVTT

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

00:00:10.500 --> 00:00:12.270
>> Hola mi nombre es Pam,

00:00:12.270 --> 00:00:15.495
y soy Gerente de Programas con
el equipo de ingeniería de SQL Server.

00:00:15.495 --> 00:00:17.790
Hoy me gustaría hacer
una demostración rápida para usted

00:00:17.790 --> 00:00:19.800
en uno de los nuevos
características de SQL Server.

00:00:19.800 --> 00:00:23.310
2019 Memoria optimizada
Metadatos de TempDB.

00:00:23.310 --> 00:00:26.070
Ya he hecho un
vídeo de visión general sobre

00:00:26.070 --> 00:00:27.480
esta característica donde
Hablo un poco

00:00:27.480 --> 00:00:29.040
acerca de algunos de los desafíos con

00:00:29.040 --> 00:00:32.295
Rendimiento de TempDB que
puede haber enfrentado en el pasado y

00:00:32.295 --> 00:00:35.850
sobre el trabajo que estamos haciendo en 2019
para mejorar el rendimiento de TempDB.

00:00:35.850 --> 00:00:38.945
Así que los animo a ver que
vídeo si aún no lo has visto.

00:00:38.945 --> 00:00:41.600
Lo que vamos a hacer
en esta demostración de hoy es

00:00:41.600 --> 00:00:45.185
centrándose en la memoria optimizada
Característica de metadatos TempDB,

00:00:45.185 --> 00:00:46.805
cómo lo habilitas,

00:00:46.805 --> 00:00:47.975
cómo lo desactivaría.

00:00:47.975 --> 00:00:49.640
Pero también, ¿cómo puedes

00:00:49.640 --> 00:00:51.790
decir si usted necesita
activar esta función.

00:00:51.790 --> 00:00:55.600
¿Está teniendo el problema de que
esta característica está diseñada para resolver?

00:00:55.600 --> 00:00:58.770
Así que vamos a saltar a la
demostración y echar un vistazo.

00:01:00.220 --> 00:01:02.960
Así que tengo un cuaderno abierto aquí en

00:01:02.960 --> 00:01:05.420
Azure Data Studio
con unos pocos comandos.

00:01:05.420 --> 00:01:09.050
Lo que vamos a empezar es correr
la carga de trabajo en SQL Server.

00:01:09.050 --> 00:01:14.315
2019 sin habilitar la Memoria
Función de metadatos TempDB optimizada

00:01:14.315 --> 00:01:15.560
y vamos a tratar de echar un vistazo a

00:01:15.560 --> 00:01:17.930
esta afirmación de que
puede suceder en TempDB.

00:01:17.930 --> 00:01:21.050
Así que lo primero que soy
va a hacer es empezar

00:01:21.050 --> 00:01:24.170
un monitor de rendimiento
recoger y recoger

00:01:24.170 --> 00:01:26.120
algunos diferentes
contadores que darán

00:01:26.120 --> 00:01:28.430
una idea de la
rendimiento de la carga de trabajo.

00:01:28.430 --> 00:01:31.955
Entonces voy a usar
la herramienta de estrés O

00:01:31.955 --> 00:01:34.415
para ejecutar una carga de trabajo multiproceso.

00:01:34.415 --> 00:01:37.700
Así que tengo ocho procesadores
en esta máquina en particular,

00:01:37.700 --> 00:01:39.950
pero estoy lanzando 100
hilos simultáneos.

00:01:39.950 --> 00:01:42.350
Así que tengo una carga de trabajo muy ocupada

00:01:42.350 --> 00:01:44.810
aquí y es un muy
pesada carga de trabajo de TempDB.

00:01:44.810 --> 00:01:47.210
Es un procedimiento almacenado básico
que crea una tabla temporal,

00:01:47.210 --> 00:01:48.360
poner algunos datos en él,

00:01:48.360 --> 00:01:49.805
y luego selecciona de él.

00:01:49.805 --> 00:01:52.200
Así que puedes ver aquí en Perf hombre.

00:01:52.200 --> 00:01:54.090
Tengo algunos pesos en curso,

00:01:54.090 --> 00:01:55.740
pestillos de página en curso.

00:01:55.740 --> 00:01:58.895
También tengo el tiempo de espera promedio

00:01:58.895 --> 00:02:00.380
aquí en Perf hombre también.

00:02:00.380 --> 00:02:02.390
Así que puedes ver que tengo
pesos de pestillo paginados

00:02:02.390 --> 00:02:04.775
sucediendo mientras estoy
ejecutando esta carga de trabajo.

00:02:04.775 --> 00:02:07.640
Eso no es inusual con un
carga de trabajo muy simultánea.

00:02:07.640 --> 00:02:11.580
La pregunta aquí es ¿cuáles son los
estos pesos de pestillo de página de?

00:02:11.580 --> 00:02:12.770
No lo sabemos necesariamente.

00:02:12.770 --> 00:02:14.405
Podrían ser de
su base de datos de usuarios.

00:02:14.405 --> 00:02:16.430
Podrían ser de TempDB.

00:02:16.430 --> 00:02:18.740
Realmente no sabemos sólo
mirando el rendimiento

00:02:18.740 --> 00:02:21.620
monitor donde estas páginas se bloquean
pesos están viniendo de.

00:02:21.620 --> 00:02:23.210
Así que queremos volver a

00:02:23.210 --> 00:02:25.850
Azure Data Studio y eche un vistazo a

00:02:25.850 --> 00:02:27.110
un guión que nos puede ayudar

00:02:27.110 --> 00:02:30.880
determinar dónde estas páginas
los pesos de los pestillos vienen de.

00:02:30.880 --> 00:02:32.230
Parece que mi carga de trabajo terminó.

00:02:32.230 --> 00:02:34.190
Así que voy a patearlo
volver a salir de nuevo para que

00:02:34.190 --> 00:02:36.925
puede ver ese Azure Data Studio.

00:02:36.925 --> 00:02:40.090
Así que volvamos aquí.

00:02:42.130 --> 00:02:47.135
Voy a ejecutar esta consulta
que tengo en el foco.

00:02:47.135 --> 00:02:51.740
Lo que esta consulta está haciendo es
mirando todas las peticiones de

00:02:51.740 --> 00:02:56.510
DM solicitud exacta que tienen
un tipo de peso como página,

00:02:56.510 --> 00:03:00.335
lo que significa algún tipo de
pestillo de página.

00:03:00.335 --> 00:03:04.010
Lo que puedo ver en los resultados
aquí es que en realidad tengo

00:03:04.010 --> 00:03:07.295
varias sesiones que son
esperando en el pestillo de la página.

00:03:07.295 --> 00:03:09.305
Si miro el recurso de peso,

00:03:09.305 --> 00:03:11.990
Me doy cuenta sólo por el peso
recurso en el que están

00:03:11.990 --> 00:03:15.905
TempDB porque el peso
recurso aquí es 2:1:1:20.

00:03:15.905 --> 00:03:17.420
Dos es ID de base de datos,

00:03:17.420 --> 00:03:18.665
dos que es TempDB.

00:03:18.665 --> 00:03:23.570
Uno es el archivo número 1 y
entonces 120 es el número de página.

00:03:23.570 --> 00:03:25.325
Así que puedo decir que está en TempDB.

00:03:25.325 --> 00:03:30.395
Pero si uso esta nueva función
llamada información de la página DMDB,

00:03:30.395 --> 00:03:34.039
lo que esto me permite hacer
es tomar ese recurso de página

00:03:34.039 --> 00:03:38.330
y abrirlo y ver
lo que está exactamente en esa página.

00:03:38.330 --> 00:03:41.355
Así que desde esa función de información de la página DMDB,

00:03:41.355 --> 00:03:44.150
Entiendo este objeto
nombre y se puede ver

00:03:44.150 --> 00:03:46.810
aquí que el nombre del objeto
es sys objetos de esquema,

00:03:46.810 --> 00:03:48.095
que es una tabla del sistema.

00:03:48.095 --> 00:03:50.944
Así que esto es que TempDB
contención de metadatos

00:03:50.944 --> 00:03:52.685
de lo que estábamos hablando.

00:03:52.685 --> 00:03:54.754
Este es el problema

00:03:54.754 --> 00:03:58.220
que la tempDB optimizada para memoria
metadatos se introdujeron para resolver.

00:03:58.220 --> 00:03:59.960
Así que volvamos a
nuestra ventana de comandos.

00:03:59.960 --> 00:04:01.115
Podemos ver que terminó.

00:04:01.115 --> 00:04:02.450
Ambas veces se ejecutó,

00:04:02.450 --> 00:04:06.005
tomó unos 52 segundos
para ejecutar la carga de trabajo.

00:04:06.005 --> 00:04:09.675
Por supuesto, podemos ver la página
cierre de pesos sucediendo.

00:04:09.675 --> 00:04:12.300
Podemos ver el lote
solicitudes por segundo,

00:04:12.300 --> 00:04:14.100
que están rematando en,

00:04:14.100 --> 00:04:18.225
vamos a ver aquí, alrededor de 350 máximo.

00:04:18.225 --> 00:04:20.210
Así que eso es sin el
función activada.

00:04:20.210 --> 00:04:22.265
Así que vamos a seguir adelante y
activar la función.

00:04:22.265 --> 00:04:23.795
Para hacer eso,

00:04:23.795 --> 00:04:25.925
tenemos que habilitar la función en

00:04:25.925 --> 00:04:29.090
SQL Server y también necesitamos
para reiniciar el servidor.

00:04:29.090 --> 00:04:34.250
Esto altera la configuración del servidor
comando aquí requiere un reinicio.

00:04:34.250 --> 00:04:38.875
Así que vamos a establecer esa memoria
Metadatos de TempDB optimizados activados.

00:04:38.875 --> 00:04:43.540
Entonces seguiré adelante y
reiniciar el servidor.

00:04:44.360 --> 00:04:48.025
Entonces una vez que haga eso,

00:04:48.025 --> 00:04:50.810
Seré capaz de volver

00:04:50.810 --> 00:04:54.155
a Azure Data Studio y
ejecutar otro comando,

00:04:54.155 --> 00:04:57.470
seleccionar la propiedad del servidor
comando para ver si

00:04:57.470 --> 00:05:01.160
la memoria TempDB optimizada
la función de metadatos está activada.

00:05:01.160 --> 00:05:03.265
Así que vamos a ejecutar este comando.

00:05:03.265 --> 00:05:07.245
Se puede ver que se ejecuta
y la función ya está activada.

00:05:07.245 --> 00:05:10.565
Es uno. Así que vamos a seguir adelante
y ejecutar nuestra carga de trabajo de nuevo.

00:05:10.565 --> 00:05:13.470
Empecemos por el hombre Perf.

00:05:16.490 --> 00:05:19.350
Empecemos de nuevo con nuestra carga de trabajo.

00:05:19.350 --> 00:05:20.775
Cargas de trabajo exactas.

00:05:20.775 --> 00:05:24.130
El mismo procedimiento almacenado, 100 subprocesos.

00:05:24.130 --> 00:05:27.080
Usted puede notar algo
diferente en El hombre de Perf de inmediato.

00:05:27.080 --> 00:05:29.900
En primer lugar, las solicitudes por lotes
por segundo es mucho más alto.

00:05:29.900 --> 00:05:34.520
Vamos a más de 500.

00:05:34.520 --> 00:05:36.320
Incluso podría ir un poco más alto.

00:05:36.320 --> 00:05:37.580
Dejaré que eso corra por un tiempo,

00:05:37.580 --> 00:05:40.790
pero también notar esas páginas
los pesos de cierre se han ido.

00:05:40.790 --> 00:05:42.605
No más pesos de pestillo de página.

00:05:42.605 --> 00:05:45.740
Si volvemos a Azure Data
Studio y yo ejecutamos ese comando

00:05:45.740 --> 00:05:48.990
de nuevo para mirar las sesiones.

00:05:48.990 --> 00:05:52.310
Observe que no hay sesiones
que están esperando en el pestillo de la página.

00:05:52.310 --> 00:05:55.865
Hemos eliminado por completo
los pesos del pestillo de la página.

00:05:55.865 --> 00:05:57.590
Si vuelvo con el hombre Perf,

00:05:57.590 --> 00:06:00.005
Sí, mi carga de trabajo ya ha terminado.

00:06:00.005 --> 00:06:02.990
Así que pueden ver que he
rendimiento mejorado.

00:06:02.990 --> 00:06:05.675
He eliminado a esos
pestillos de página.

00:06:05.675 --> 00:06:07.580
Si me voy a la carga de trabajo,

00:06:07.580 --> 00:06:10.130
ahora se ha completado en 35 segundos

00:06:10.130 --> 00:06:13.760
frente a los 52 segundos
sin la función encendida.

00:06:13.760 --> 00:06:19.220
Así que esta característica está diseñada
para permitirle ayudar a escalar

00:06:19.220 --> 00:06:23.240
hasta su pesado TempDB
cargas de trabajo contenciosas

00:06:23.240 --> 00:06:25.400
sin hacer ninguna
cambios de código en absoluto.

00:06:25.400 --> 00:06:28.085
Simplemente encienda la configuración,

00:06:28.085 --> 00:06:31.640
reiniciar el servidor y luego
puede haber mejorado inmediatamente

00:06:31.640 --> 00:06:33.770
rendimiento y menos
pesos de pestillo de página

00:06:33.770 --> 00:06:36.320
en sus cargas de trabajo contenciosas de TempDB.

00:06:36.320 --> 00:06:38.300
Así que espero que eso te ayude a aprender

00:06:38.300 --> 00:06:40.790
un poco más sobre el
característica, cómo lo usaría,

00:06:40.790 --> 00:06:42.860
cómo sabrías si
es necesario encenderlo

00:06:42.860 --> 00:06:45.020
o no y te hace un poco más

00:06:45.020 --> 00:06:46.970
entusiasmado por las mejoras
que están entrando

00:06:46.970 --> 00:06:49.610
SQL Server 2019 Muchas gracias.

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