WEBVTT

00:00:00.000 --> 00:00:02.055
Восстановление базы данных с

00:00:02.055 --> 00:00:05.190
долгосрочные транзакции
был вызов.

00:00:05.190 --> 00:00:07.050
В сервере S'L 2019,

00:00:07.050 --> 00:00:09.780
мы вводим ускоренный
восстановление базы данных

00:00:09.780 --> 00:00:11.190
чтобы помочь решить эту проблему.

00:00:11.190 --> 00:00:13.605
Кевин здесь, чтобы сказать
нас все об этом,

00:00:13.605 --> 00:00:15.390
сегодня на данные разоблачены.

00:00:15.390 --> 00:00:26.130
(МУЗЫКА)

00:00:26.130 --> 00:00:28.755
Привет и добро пожаловать в другой
эпизод данных разоблачены.

00:00:28.755 --> 00:00:30.745
Я твой хозяин, Джеруан, и сегодня,

00:00:30.745 --> 00:00:34.415
у нас есть Кевин с нами, чтобы говорить о
ускоренное восстановление базы данных.

00:00:34.415 --> 00:00:35.975
Так что добро пожаловать Кевин на шоу.

00:00:35.975 --> 00:00:36.665
Спасибо.

00:00:36.665 --> 00:00:39.125
Так ускоренное восстановление базы данных.

00:00:39.125 --> 00:00:40.750
Так что же это такое?

00:00:40.750 --> 00:00:41.930
Так что это интересная особенность.

00:00:41.930 --> 00:00:43.340
Мы назовем это ADR для краткости.

00:00:43.340 --> 00:00:44.890
Хорошо, конечно.

00:00:44.890 --> 00:00:46.970
Он пришел из
глядя на некоторые из

00:00:46.970 --> 00:00:48.530
болевые точки, что клиенты имели

00:00:48.530 --> 00:00:51.770
запуск баз данных и хранение
их весьма доступны и

00:00:51.770 --> 00:00:53.270
часть его связано со временем, что

00:00:53.270 --> 00:00:55.475
принимает, чтобы привести базу данных в Интернете.

00:00:55.475 --> 00:00:58.970
Есть ряд этапов, которые
база данных должна пройти,

00:00:58.970 --> 00:01:01.340
и если у вас есть длинный
ходовая транзакция,

00:01:01.340 --> 00:01:04.010
это может занять много времени
чтобы очистить, что и что

00:01:04.010 --> 00:01:07.080
приводит к недоступности, когда
он делает эту обработку.

00:01:07.080 --> 00:01:10.545
В-право. Таким образом, мы знаем, что
восстановление является болевой точкой.

00:01:10.545 --> 00:01:13.530
Вернуть его - это
то, что dBAs,

00:01:13.530 --> 00:01:15.075
Ну, вроде беспокоиться о.

00:01:15.075 --> 00:01:16.790
В-право. Таким образом, команда посмотрела на

00:01:16.790 --> 00:01:19.520
что весь процесс и мысли
как мы можем переосмыслить это?

00:01:19.520 --> 00:01:21.335
Итак, они придумали ADR,

00:01:21.335 --> 00:01:23.210
он основан на магазине версий.

00:01:23.210 --> 00:01:26.170
Таким образом, все изменения
версии в базе данных.

00:01:26.170 --> 00:01:29.920
Это живет в файле
группа по вашему выбору.

00:01:30.140 --> 00:01:34.925
Используя это, мы можем сделать
процесс восстановления гораздо быстрее.

00:01:34.925 --> 00:01:35.600
Прохладный.

00:01:35.600 --> 00:01:40.965
У меня есть несколько слайдов
которые демонстрируют.

00:01:40.965 --> 00:01:46.515
Так вот у нас есть
классический процесс восстановления.

00:01:46.515 --> 00:01:48.350
Итак, он начинается, Фаза 1 является анализ.

00:01:48.350 --> 00:01:50.360
Таким образом, вы должны смотреть через
все транзакции

00:01:50.360 --> 00:01:53.020
в журнале из последнего
контрольно-пропускной пункт вперед.

00:01:53.020 --> 00:01:56.150
Redo — это любые изменения данных

00:01:56.150 --> 00:01:58.700
, которые не были упорствоваты
в файлах данных,

00:01:58.700 --> 00:02:01.850
должны быть перемеженные из
журнал транзакций,

00:02:01.850 --> 00:02:03.020
на всем пути от

00:02:03.020 --> 00:02:05.420
начало самого старого,
незафиксированных транзакций.

00:02:05.420 --> 00:02:07.790
Так вот где долгосрочные
сделки действительно больно вам.

00:02:07.790 --> 00:02:08.560
Правильно, точно.

00:02:08.560 --> 00:02:12.170
Может занять несколько минут, чтобы
час или более иногда.

00:02:12.170 --> 00:02:14.660
Затем, Фаза 3 отменить,

00:02:14.660 --> 00:02:17.270
где вы отменить любые операции, которые

00:02:17.270 --> 00:02:20.975
не были совершены до
время вы с нетерпением ждем.

00:02:20.975 --> 00:02:23.285
Во время окончания чтения,

00:02:23.285 --> 00:02:25.375
база данных частично доступна.

00:02:25.375 --> 00:02:28.670
Это значит, что вы можете
доступ к базе данных, но

00:02:28.670 --> 00:02:33.270
любые данные, которые не были под замком
из исходных транзакций,

00:02:33.270 --> 00:02:34.320
будет под замком сейчас.

00:02:34.320 --> 00:02:36.200
Таким образом, даже если есть
никто не делает их,

00:02:36.200 --> 00:02:39.230
вы не можете получить доступ к этим данным
до тех пор, пока отменить завершает.

00:02:39.230 --> 00:02:41.930
Так что в основном это
длительный процесс

00:02:41.930 --> 00:02:45.835
, а затем только после
мы приходим к фазе 3,

00:02:45.835 --> 00:02:47.900
Я могу начать делать

00:02:47.900 --> 00:02:49.580
все, что я хотел с
базы данных снова, не так ли?

00:02:49.580 --> 00:02:50.165
В-право.

00:02:50.165 --> 00:02:53.585
Так что расскажи мне, как это было.

00:02:53.585 --> 00:02:55.865
На дне вы видите только

00:02:55.865 --> 00:02:59.145
запись журнала с различными
события в записи журнала.

00:02:59.145 --> 00:03:00.165
Конечно же.

00:03:00.165 --> 00:03:02.190
ADR меняет это много.

00:03:02.190 --> 00:03:03.750
У нас есть магазин обрабатывающих версий.

00:03:03.750 --> 00:03:06.375
Вы увидите его ссылки как PVS.

00:03:06.375 --> 00:03:09.464
Когда мы помещаем это в превью,

00:03:09.464 --> 00:03:11.915
PVS жил в основной группе файлов

00:03:11.915 --> 00:03:13.820
и нет никакой способности
изменить это.

00:03:13.820 --> 00:03:16.780
Так что и произошло, вот где
все эти версии жили.

00:03:16.780 --> 00:03:19.550
Мы получили обратную связь, что
клиенты хотели бы

00:03:19.550 --> 00:03:22.280
быть в состоянии указать, какие
файл группы, которая живет дюйма

00:03:22.280 --> 00:03:26.180
У меня есть группа объемных файлов или
очень быстрая группа файлов, независимо.

00:03:26.180 --> 00:03:27.740
Так что теперь вы с

00:03:27.740 --> 00:03:31.130
релиз кандидата и с
версия GA, когда она выходит,

00:03:31.130 --> 00:03:33.910
вы сможете указать, какие
файл группы и изменить его,

00:03:33.910 --> 00:03:35.880
есть процесс для
изменить его, а также.

00:03:35.880 --> 00:03:38.120
Но давайте пройдем через то, что
процесс восстановления

00:03:38.120 --> 00:03:39.755
похоже на ADR.

00:03:39.755 --> 00:03:42.110
Итак, все начинается с анализа,

00:03:42.110 --> 00:03:45.695
, которая не меняется от
то, что у вас было раньше.

00:03:45.695 --> 00:03:47.015
Это то же самое поведение, не так ли?

00:03:47.015 --> 00:03:49.805
В-право. Мы представили
концепция sLog.

00:03:49.805 --> 00:03:52.705
SLog — это журнал памяти

00:03:52.705 --> 00:03:55.640
что записывает только те,
системные транзакции

00:03:55.640 --> 00:03:57.005
которые не могут быть версиированы.

00:03:57.005 --> 00:03:59.150
Таким образом, большинство версий данных вы можете

00:03:59.150 --> 00:04:01.715
изменения до и после
фотографии данных.

00:04:01.715 --> 00:04:04.070
Таким образом, некоторые изменения схемы,

00:04:04.070 --> 00:04:06.195
некоторые вещи, как, что,
не может быть версия.

00:04:06.195 --> 00:04:06.570
Конечно же.

00:04:06.570 --> 00:04:07.890
Так что те, которые записываются в sLog.

00:04:07.890 --> 00:04:09.195
Идея в том, что это,

00:04:09.195 --> 00:04:11.580
очень мало значительных.

00:04:11.580 --> 00:04:13.920
Будет небольшой
набор прогнозов, не так ли?

00:04:13.920 --> 00:04:17.525
Так что часть анализа
и переделать фазы

00:04:17.525 --> 00:04:23.100
воссоздание этих журналов памяти
из записей журнала транзакций.

00:04:23.230 --> 00:04:25.850
Так что переделать из sLog,

00:04:25.850 --> 00:04:28.300
просто используя версию магазина.

00:04:28.300 --> 00:04:31.195
Потому что у нас есть до и после
версии всех этих строк,

00:04:31.195 --> 00:04:34.010
так что это очень быстро и
то вы переделать из

00:04:34.010 --> 00:04:38.905
журнал только из
последний контрольно-пропускной пункт вперед.

00:04:38.905 --> 00:04:42.810
На этом этапе ваша база данных
полностью доступен.

00:04:43.420 --> 00:04:46.910
Отменить это просто возвращение

00:04:46.910 --> 00:04:48.875
версии, так что вы просто

00:04:48.875 --> 00:04:51.710
указать на предыдущую версию
вместо текущей версии.

00:04:51.710 --> 00:04:55.345
Вы не должны физически отменить
транзакции и обратной версии.

00:04:55.345 --> 00:04:59.825
Так что это будет путь
быстрее, чем старый обычно?

00:04:59.825 --> 00:05:01.880
Путь быстрее. У нас был клиент в

00:05:01.880 --> 00:05:04.280
лаборатории в течение последних нескольких
недель, которые сделали некоторые испытания с

00:05:04.280 --> 00:05:10.050
ADR, и у них был очень
активная рабочая нагрузка обновления.

00:05:10.050 --> 00:05:13.065
У них был длительный
сделки с ним.

00:05:13.065 --> 00:05:14.430
Они сделали это, это,

00:05:14.430 --> 00:05:17.450
и сделал откат, что
длительная транзакция.

00:05:17.450 --> 00:05:20.555
Без ADR потребовалось около
минута-и-полтора, чтобы сделать это.

00:05:20.555 --> 00:05:24.765
- Что до сих пор не
слишком плохо, но хорошо, долго.

00:05:24.765 --> 00:05:26.190
Да, да. В своем бизнесе

00:05:26.190 --> 00:05:28.105
это имеет большое значение.

00:05:28.105 --> 00:05:30.680
Итогда они повторили
тот же сценарий

00:05:30.680 --> 00:05:32.780
с ADR и время, задетое

00:05:32.780 --> 00:05:36.720
для этого восстановление было ноль секунд.

00:05:36.720 --> 00:05:38.505
Они не могли измерить
это было так быстро.

00:05:38.505 --> 00:05:40.110
Впечатляет.

00:05:40.110 --> 00:05:43.580
Так что для них, они вернулись
на линии, что гораздо быстрее,

00:05:43.580 --> 00:05:47.425
что имеет большое значение
тоже, потому что в их бизнесе,

00:05:47.425 --> 00:05:49.560
любые перебои - это потеря дохода.

00:05:49.560 --> 00:05:51.375
Так миллисекунды считаются, не так ли?

00:05:51.375 --> 00:05:52.230
Очень сильно.

00:05:52.230 --> 00:05:53.880
Так что, если мы можем помочь этому клиенту

00:05:53.880 --> 00:05:55.575
переехал с полутора минут,

00:05:55.575 --> 00:05:58.305
Вы сказали, в основном ноль,

00:05:58.305 --> 00:05:59.895
это впечатляет. Так ничего себе.

00:05:59.895 --> 00:06:02.930
Таким образом, все наши клиенты

00:06:02.930 --> 00:06:05.810
вероятно, желая
попробуйте это и включите это.

00:06:05.810 --> 00:06:08.450
Так ты можешь рассказать мне, как я это делаю?

00:06:08.450 --> 00:06:09.470
У меня есть база данных,

00:06:09.470 --> 00:06:12.995
У меня это на нормальном
восстановления, так что мне делать?

00:06:12.995 --> 00:06:14.585
Так что с базой данных Azure S'L,

00:06:14.585 --> 00:06:16.775
он по умолчанию глобально.

00:06:16.775 --> 00:06:19.130
Он был на по умолчанию
глобально в течение нескольких месяцев.

00:06:19.130 --> 00:06:20.540
Таким образом, вам не нужно
делать что-нибудь там.

00:06:20.540 --> 00:06:22.520
Ты уже воспользовался этим.

00:06:22.520 --> 00:06:23.740
Прохладный.

00:06:23.740 --> 00:06:26.940
Для баз данных сервера S'L,

00:06:26.940 --> 00:06:29.060
он выключен по умолчанию, потому что есть

00:06:29.060 --> 00:06:31.610
некоторые накладные расходы на диапазоне

00:06:31.610 --> 00:06:35.880
от одного до пяти процентов для
отслеживание версий.

00:06:36.190 --> 00:06:41.015
Таким образом, вам придется включить его и
это просто, изменить набор баз данных,

00:06:41.015 --> 00:06:42.635
ускоренное восстановление базы данных равно

00:06:42.635 --> 00:06:46.410
и дополнительно с
файл группа равна.

00:06:46.410 --> 00:06:47.310
Что-то.

00:06:47.310 --> 00:06:49.810
Да, да. Так очень просто DDL.

00:06:49.810 --> 00:06:51.710
Вопрос: Что тогда происходит?

00:06:51.710 --> 00:06:54.410
Затем он начинает отслеживать
версии, и вы получите выгоду.

00:06:54.410 --> 00:06:55.970
Прохладный. Это прямо,

00:06:55.970 --> 00:06:58.065
немедленно, или это нравится,

00:06:58.065 --> 00:06:59.250
требуется перезагрузка.

00:06:59.250 --> 00:07:01.740
Нет перезагрузки. Ты просто в сети.

00:07:01.740 --> 00:07:03.705
Прохладный. Так ничего себе.

00:07:03.705 --> 00:07:05.160
Так что в основном, это как

00:07:05.160 --> 00:07:08.545
очень здорово технологии для
восстановить базу данных очень быстро.

00:07:08.545 --> 00:07:10.730
Что-нибудь еще, что я получаю от этого?

00:07:10.730 --> 00:07:12.140
Я имею в виду это действительно
очень впечатляет, но

00:07:12.140 --> 00:07:13.580
это как дополнительные преимущества.

00:07:13.580 --> 00:07:15.590
Так что есть дополнительное преимущество в

00:07:15.590 --> 00:07:19.115
что из-за пути
мы повторно используем версии,

00:07:19.115 --> 00:07:22.470
мы не должны держать, как
много транзакций журнала в Интернете.

00:07:22.470 --> 00:07:24.920
Таким образом, вы можете усечение
транзакции журнал гораздо больше

00:07:24.920 --> 00:07:28.725
агрессивно до последнего
контрольно-пропускной пункт, чем вы могли раньше.

00:07:28.725 --> 00:07:30.530
Это означает, что если вы
получил ситуацию,

00:07:30.530 --> 00:07:32.540
у нас есть долгосрочные
транзакции, которая держит вас

00:07:32.540 --> 00:07:34.460
от возможности усечь

00:07:34.460 --> 00:07:36.620
ваш журнал и транзакция
журнал начинает взрываться,

00:07:36.620 --> 00:07:38.665
что не происходит
с ADR включен.

00:07:38.665 --> 00:07:41.400
Так что в основном это
дополнительное преимущество.

00:07:41.400 --> 00:07:43.650
Нет длинной транзакции
журнал перетаскивания вдоль.

00:07:43.650 --> 00:07:44.505
Точно.

00:07:44.505 --> 00:07:45.990
Я знаю, что я буду делать,

00:07:45.990 --> 00:07:47.660
Я имею в виду MyS'L сервер был перейти к

00:07:47.660 --> 00:07:49.760
ускорить базу данных
восстановления прямо сейчас.

00:07:49.760 --> 00:07:51.470
После этого видео, я сделаю это.

00:07:51.470 --> 00:07:52.805
Большое спасибо за обмен.

00:07:52.805 --> 00:07:53.345
Спасибо.

00:07:53.345 --> 00:07:55.940
Спасибо за объяснение.
Это было очень ясно.

00:07:55.940 --> 00:07:57.575
Спасибо, что смотрели.

00:07:57.575 --> 00:08:00.990
Пожалуйста, нравится и подписаться и
следите за обновлениями на следующий. Спасибо.

00:08:00.990 --> 00:08:13.210
(МУЗЫКА)