WEBVTT

00:00:00.000 --> 00:00:02.055
>> Recuperación de bases de datos con

00:00:02.055 --> 00:00:05.190
transacciones de larga duración
ha sido un desafío.

00:00:05.190 --> 00:00:07.050
En SQL Server 2019,

00:00:07.050 --> 00:00:09.780
introducimos acelerado
recuperación de la base de datos

00:00:09.780 --> 00:00:11.190
para ayudar a resolver ese problema.

00:00:11.190 --> 00:00:13.605
Kevin está aquí para contar
todo sobre eso,

00:00:13.605 --> 00:00:15.390
hoy en Data Exposed.

00:00:15.390 --> 00:00:26.130
[MUSICA]

00:00:26.130 --> 00:00:28.755
>> Hola y bienvenidos a otro
episodio de Data Exposed.

00:00:28.755 --> 00:00:30.745
Soy tu anfitrión, Jeroen y hoy,

00:00:30.745 --> 00:00:34.415
tenemos a Kevin con nosotros para hablar de
recuperación acelerada de la base de datos.

00:00:34.415 --> 00:00:35.975
Así que bienvenido a Kevin al show.

00:00:35.975 --> 00:00:36.665
>> Gracias.

00:00:36.665 --> 00:00:39.125
>> Así que la recuperación acelerada de la base de datos.

00:00:39.125 --> 00:00:40.750
Entonces, ¿qué pasa?

00:00:40.750 --> 00:00:41.930
>> Así que es una característica interesante.

00:00:41.930 --> 00:00:43.340
Lo llamaremos ADR para abreviar.

00:00:43.340 --> 00:00:44.890
>> De acuerdo, claro.

00:00:44.890 --> 00:00:46.970
>> Vino de
mirando a algunos de los

00:00:46.970 --> 00:00:48.530
puntos de dolor que los clientes han tenido

00:00:48.530 --> 00:00:51.770
ejecutar bases de datos y mantener
ellos altamente disponibles y

00:00:51.770 --> 00:00:53.270
parte de ella tiene que ver con el tiempo que

00:00:53.270 --> 00:00:55.475
para poner una base de datos en línea.

00:00:55.475 --> 00:00:58.970
Hay una serie de fases que
una base de datos tiene que llegar a través,

00:00:58.970 --> 00:01:01.340
y si tienes un largo
ejecución de la transacción,

00:01:01.340 --> 00:01:04.010
puede tomar mucho tiempo
para limpiar eso y que

00:01:04.010 --> 00:01:07.080
conduce a la indisponibilidad cuando
está haciendo ese procesamiento.

00:01:07.080 --> 00:01:10.545
>> Correcto. Así que sabemos que
restaurar es un punto de dolor.

00:01:10.545 --> 00:01:13.530
Traerlo de vuelta es
algo que DBAs,

00:01:13.530 --> 00:01:15.075
bueno, un poco de preocupación por.

00:01:15.075 --> 00:01:16.790
>> Correcto. Así que el equipo miró

00:01:16.790 --> 00:01:19.520
todo ese proceso y pensamiento
¿cómo podemos reimaginarlo?

00:01:19.520 --> 00:01:21.335
Así que se les ocurrió ADR,

00:01:21.335 --> 00:01:23.210
se basa en una tienda de versiones.

00:01:23.210 --> 00:01:26.170
Así que todos los cambios son
versión en la base de datos.

00:01:26.170 --> 00:01:29.920
Que vive en el archivo
grupo de su elección.

00:01:30.140 --> 00:01:34.925
Aprovechando eso, podemos hacer que el
proceso de recuperación mucho más rápido.

00:01:34.925 --> 00:01:35.600
>> Genial.

00:01:35.600 --> 00:01:40.965
>> Tengo algunas diapositivas
que demuestran.

00:01:40.965 --> 00:01:46.515
Así que aquí tenemos el
proceso de recuperación clásico.

00:01:46.515 --> 00:01:48.350
Así que comienza, La Fase 1 es el análisis.

00:01:48.350 --> 00:01:50.360
Así que tienes que mirar a través de
todas las transacciones

00:01:50.360 --> 00:01:53.020
en el registro de la última
punto de control hacia adelante.

00:01:53.020 --> 00:01:56.150
Rehacer es cualquier cambio de datos

00:01:56.150 --> 00:01:58.700
que no se ha perserve
en los archivos de datos,

00:01:58.700 --> 00:02:01.850
tienen que ser rehechos de
el registro de transacciones,

00:02:01.850 --> 00:02:03.020
todo el camino a través de

00:02:03.020 --> 00:02:05.420
el comienzo de la más antigua,
transacciones no confirmadas.

00:02:05.420 --> 00:02:07.790
Así que ahí es donde el largo plazo
las transacciones realmente le hacen daño.

00:02:07.790 --> 00:02:08.560
>> Correcto, exactamente.

00:02:08.560 --> 00:02:12.170
>> Puede tomar un minuto para
una hora o más a veces.

00:02:12.170 --> 00:02:14.660
Entonces, la Fase 3 es deshacer,

00:02:14.660 --> 00:02:17.270
donde se deshace cualquier transacción que

00:02:17.270 --> 00:02:20.975
no se cometieron antes de la
tiempo que esperas con ansias.

00:02:20.975 --> 00:02:23.285
En el momento en que termina la lectura,

00:02:23.285 --> 00:02:25.375
la base de datos está parcialmente disponible.

00:02:25.375 --> 00:02:28.670
Lo que eso significa es que puedes
acceder a la base de datos, pero

00:02:28.670 --> 00:02:33.270
cualquier dato que no estaba bajo llave
de las transacciones originales,

00:02:33.270 --> 00:02:34.320
estará bajo llave ahora.

00:02:34.320 --> 00:02:36.200
Así que a pesar de que hay
nadie los hace,

00:02:36.200 --> 00:02:39.230
no se puede acceder a esos datos
hasta que se complete el deshacer.

00:02:39.230 --> 00:02:41.930
>> Así que básicamente esto es
un proceso de larga duración

00:02:41.930 --> 00:02:45.835
y luego sólo después de
llegamos a la Fase 3,

00:02:45.835 --> 00:02:47.900
Puedo empezar a hacer

00:02:47.900 --> 00:02:49.580
todo lo que quería con
la base de datos de nuevo, ¿verdad?

00:02:49.580 --> 00:02:50.165
>> Correcto.

00:02:50.165 --> 00:02:53.585
>> Así que dime cómo fue.

00:02:53.585 --> 00:02:55.865
>> En la parte inferior, se ve

00:02:55.865 --> 00:02:59.145
registro de registro con diferentes
eventos en el registro.

00:02:59.145 --> 00:03:00.165
>> Claro.

00:03:00.165 --> 00:03:02.190
>> ADR cambia mucho.

00:03:02.190 --> 00:03:03.750
Tenemos el almacén de versiones de procesamiento.

00:03:03.750 --> 00:03:06.375
Verá que se hace referencia como PVS.

00:03:06.375 --> 00:03:09.464
Cuando lo ponemos en las vistas previas,

00:03:09.464 --> 00:03:11.915
PVS vivió en el grupo de archivos primario

00:03:11.915 --> 00:03:13.820
y no hay capacidad
para cambiar eso.

00:03:13.820 --> 00:03:16.780
Así que eso sucedió, ahí es donde
todas esas versiones vivieron.

00:03:16.780 --> 00:03:19.550
Recibimos comentarios que
clientes les gustaría

00:03:19.550 --> 00:03:22.280
poder especificar qué
grupo de archivos que vive en.

00:03:22.280 --> 00:03:26.180
Tengo un grupo de archivos a granel o
grupo de archivos muy rápido, lo que sea.

00:03:26.180 --> 00:03:27.740
Así que ahora estás con

00:03:27.740 --> 00:03:31.130
el candidato de liberación y con
la versión GA cuando sale,

00:03:31.130 --> 00:03:33.910
usted será capaz de especificar qué
grupo de archivos y cambiarlo,

00:03:33.910 --> 00:03:35.880
hay proceso para
cambiarlo también.

00:03:35.880 --> 00:03:38.120
Pero vamos a ir a través de lo que
el proceso de recuperación

00:03:38.120 --> 00:03:39.755
parece que con ADR.

00:03:39.755 --> 00:03:42.110
Así que comienza con el análisis,

00:03:42.110 --> 00:03:45.695
que no ha cambiado de
lo que tenías antes.

00:03:45.695 --> 00:03:47.015
>> Es el mismo comportamiento, ¿verdad?

00:03:47.015 --> 00:03:49.805
>> Correcto. Hemos introducido
el concepto de un sLog.

00:03:49.805 --> 00:03:52.705
Un sLog es un registro en memoria

00:03:52.705 --> 00:03:55.640
que registra sólo aquellos
transacciones del sistema

00:03:55.640 --> 00:03:57.005
que no se puede versionar.

00:03:57.005 --> 00:03:59.150
Así que la mayoría de las versiones de datos que puede

00:03:59.150 --> 00:04:01.715
cambiar antes y después
imágenes de los datos.

00:04:01.715 --> 00:04:04.070
Así que algunos cambios en el esquema,

00:04:04.070 --> 00:04:06.195
algunas cosas como esa,
no se puede versionar.

00:04:06.195 --> 00:04:06.570
>> Claro.

00:04:06.570 --> 00:04:07.890
>> Así que esos se registran en el sLog.

00:04:07.890 --> 00:04:09.195
Así que la idea es que es,

00:04:09.195 --> 00:04:11.580
muy pocos significativos.

00:04:11.580 --> 00:04:13.920
>> Habrá un pequeño
conjunto de proyecciones, ¿verdad?

00:04:13.920 --> 00:04:17.525
>> Así que parte del análisis
y la fase de rehacer es

00:04:17.525 --> 00:04:23.100
recreando esos registros en memoria
de los registros de transacciones.

00:04:23.230 --> 00:04:25.850
Así que rehacer desde el sLog,

00:04:25.850 --> 00:04:28.300
está aprovechando el almacén de versiones.

00:04:28.300 --> 00:04:31.195
Porque tenemos antes y después
versiones de todas esas filas,

00:04:31.195 --> 00:04:34.010
por lo que es muy rápido y
entonces usted rehace de

00:04:34.010 --> 00:04:38.905
el registro sólo de la
último punto de control hacia adelante.

00:04:38.905 --> 00:04:42.810
En ese momento, su base de datos
está totalmente disponible.

00:04:43.420 --> 00:04:46.910
Deshacer está volviendo

00:04:46.910 --> 00:04:48.875
las versiones por lo que acaba de

00:04:48.875 --> 00:04:51.710
apuntar a la versión anterior
en lugar de la versión actual.

00:04:51.710 --> 00:04:55.345
No tienes que deshacer físicamente
la transacción y la reversión.

00:04:55.345 --> 00:04:59.825
>> Así que esto va a ser de manera
más rápido que el más viejo normalmente?

00:04:59.825 --> 00:05:01.880
>> Mucho más rápido. Teníamos un cliente en

00:05:01.880 --> 00:05:04.280
el laboratorio dentro de la última pareja de
semanas que hizo algunas pruebas con

00:05:04.280 --> 00:05:10.050
ADR y tenían un muy
carga de trabajo de actualización activa.

00:05:10.050 --> 00:05:13.065
Tuvieron una larga duración
transacción con ella.

00:05:13.065 --> 00:05:14.430
Ellos hicieron eso, esto,

00:05:14.430 --> 00:05:17.450
e hizo una reversión de que
transacción de larga duración.

00:05:17.450 --> 00:05:20.555
Sin ADR, se necesitó
minuto y medio para hacer eso.

00:05:20.555 --> 00:05:24.765
>> Que todavía no es
muy mal, pero bien, largo.

00:05:24.765 --> 00:05:26.190
>> Sí. En sus negocios,

00:05:26.190 --> 00:05:28.105
hace una gran diferencia.

00:05:28.105 --> 00:05:30.680
Entonces se reintentaron
ese mismo escenario

00:05:30.680 --> 00:05:32.780
con ADR y el tiempo que tomó

00:05:32.780 --> 00:05:36.720
para hacer esa recuperación fue de cero segundos.

00:05:36.720 --> 00:05:38.505
No podían medir
fue tan rápido.

00:05:38.505 --> 00:05:40.110
>> Eso es impresionante.

00:05:40.110 --> 00:05:43.580
>> Así que para ellos, están de vuelta
en la línea que mucho más rápido,

00:05:43.580 --> 00:05:47.425
lo que hace una gran diferencia
también porque en sus negocios,

00:05:47.425 --> 00:05:49.560
cualquier interrupción es una pérdida de ingresos.

00:05:49.560 --> 00:05:51.375
>> Así que los milisegundos cuentan, ¿verdad?

00:05:51.375 --> 00:05:52.230
>> Mucho.

00:05:52.230 --> 00:05:53.880
>> Así que si podemos ayudar a este cliente

00:05:53.880 --> 00:05:55.575
se movió de un minuto y medio,

00:05:55.575 --> 00:05:58.305
usted dijo que básicamente cero,

00:05:58.305 --> 00:05:59.895
eso es impresionante. Así que wow.

00:05:59.895 --> 00:06:02.930
Así que todos nuestros clientes

00:06:02.930 --> 00:06:05.810
probablemente están queriendo
pruebe esto y habilite esto.

00:06:05.810 --> 00:06:08.450
¿Puedes decirme cómo hago eso?

00:06:08.450 --> 00:06:09.470
Ahora tengo una base de datos,

00:06:09.470 --> 00:06:12.995
Lo tengo en el normal
recuperación, entonces, ¿qué hago?

00:06:12.995 --> 00:06:14.585
>> Así que con la base de datos SQL de Azure,

00:06:14.585 --> 00:06:16.775
está activado de forma predeterminada a nivel mundial.

00:06:16.775 --> 00:06:19.130
Ha estado activado por defecto
a nivel mundial durante meses.

00:06:19.130 --> 00:06:20.540
Así que no es necesario
hacer cualquier cosa allí.

00:06:20.540 --> 00:06:22.520
Ya te has aprovechado de ello.

00:06:22.520 --> 00:06:23.740
>> Genial.

00:06:23.740 --> 00:06:26.940
>> Para bases de datos de SQL Server,

00:06:26.940 --> 00:06:29.060
está desactivado por defecto porque hay

00:06:29.060 --> 00:06:31.610
algunos gastos generales en el rango de

00:06:31.610 --> 00:06:35.880
del uno al cinco por ciento para
realizar un seguimiento de las versiones.

00:06:36.190 --> 00:06:41.015
Así que tendrías que encenderlo y
eso es sólo, alterar el conjunto de bases de datos,

00:06:41.015 --> 00:06:42.635
recuperación acelerada de la base de datos es igual a

00:06:42.635 --> 00:06:46.410
en y opcionalmente con
grupo de archivos es igual.

00:06:46.410 --> 00:06:47.310
>> Algo.

00:06:47.310 --> 00:06:49.810
>> Sí. Tan muy simple DDL.

00:06:49.810 --> 00:06:51.710
>> Entonces, ¿qué pasa?

00:06:51.710 --> 00:06:54.410
>> Entonces comienza el seguimiento
versiones y usted obtiene el beneficio.

00:06:54.410 --> 00:06:55.970
>> Genial. ¿Es eso directo,

00:06:55.970 --> 00:06:58.065
inmediato, o es así como,

00:06:58.065 --> 00:06:59.250
se requiere un reinicio.

00:06:59.250 --> 00:07:01.740
>> Sin reinicio. Sólo estás en línea.

00:07:01.740 --> 00:07:03.705
>> Genial. Así que wow.

00:07:03.705 --> 00:07:05.160
Así que básicamente, esto es como

00:07:05.160 --> 00:07:08.545
una tecnología muy fresca para
restaurar una base de datos muy rápidamente.

00:07:08.545 --> 00:07:10.730
¿Algo más que obtenga de esto?

00:07:10.730 --> 00:07:12.140
Quiero decir que esto es realmente
muy impresionante, pero

00:07:12.140 --> 00:07:13.580
estos son como beneficios adicionales.

00:07:13.580 --> 00:07:15.590
>> Así que hay un beneficio adicional en

00:07:15.590 --> 00:07:19.115
que debido a la forma en que
reutilizamos las versiones,

00:07:19.115 --> 00:07:22.470
no tenemos que mantener como
mucho registro de transacciones en línea.

00:07:22.470 --> 00:07:24.920
Así que usted puede truncar el
registro de transacciones mucho más

00:07:24.920 --> 00:07:28.725
agresivamente hasta el último
punto de control de lo que antes.

00:07:28.725 --> 00:07:30.530
Lo que significa, si usted ha
tiene la situación,

00:07:30.530 --> 00:07:32.540
tenemos un largo plazo
transacción que te mantiene

00:07:32.540 --> 00:07:34.460
de ser capaz de truncar

00:07:34.460 --> 00:07:36.620
su registro y la transacción
el registro empieza a explotar,

00:07:36.620 --> 00:07:38.665
eso no sucede
con ADR activado.

00:07:38.665 --> 00:07:41.400
>> Así que básicamente eso es
el beneficio adicional.

00:07:41.400 --> 00:07:43.650
Sin transacción larga
registro arrastrando a lo largo.

00:07:43.650 --> 00:07:44.505
>> Exactamente.

00:07:44.505 --> 00:07:45.990
>> Sé lo que voy a hacer,

00:07:45.990 --> 00:07:47.660
Quiero decir que el servidor MySQL fue ir a

00:07:47.660 --> 00:07:49.760
acelerar una base de datos
recuperación en este momento.

00:07:49.760 --> 00:07:51.470
Después de este video, lo haré.

00:07:51.470 --> 00:07:52.805
Muchas gracias por compartir.

00:07:52.805 --> 00:07:53.345
>> Gracias.

00:07:53.345 --> 00:07:55.940
>> Gracias por explicarlo.
Esto fue muy claro.

00:07:55.940 --> 00:07:57.575
Gracias por mirar.

00:07:57.575 --> 00:08:00.990
Por favor, me gusta y suscribirse y
estar atentos para el próximo. Gracias.

00:08:00.990 --> 00:08:13.210
[MUSICA]