WEBVTT

00:00:00.000 --> 00:00:10.500
(Музыка).

00:00:10.500 --> 00:00:12.270
Привет, меня зовут Пэм,

00:00:12.270 --> 00:00:15.495
и я менеджер программы с
команда разработчиков серверов.

00:00:15.495 --> 00:00:17.790
Сегодня я хотел бы сделать
быстрое демо для вас

00:00:17.790 --> 00:00:19.800
на одном из новых
функции сервера S'L.

00:00:19.800 --> 00:00:23.310
Оптимизация памяти 2019
Метаданные TempDB.

00:00:23.310 --> 00:00:26.070
Я уже сделал
обзор видео на

00:00:26.070 --> 00:00:27.480
эта функция, где
Я немного разговариваю

00:00:27.480 --> 00:00:29.040
о некоторых проблемах с

00:00:29.040 --> 00:00:32.295
Производительность TempDB, которую вы
могли столкнуться в прошлом и

00:00:32.295 --> 00:00:35.850
о работе, которую мы делаем в 2019 году
для повышения производительности TempDB.

00:00:35.850 --> 00:00:38.945
Так что я призываю вас смотреть, что
видео, если вы еще не видели его еще.

00:00:38.945 --> 00:00:41.600
Что мы будем делать
в этом демо сегодня

00:00:41.600 --> 00:00:45.185
сосредоточение внимания на оптимизированной памяти
Функция метаданных TempDB,

00:00:45.185 --> 00:00:46.805
как вы включите его,

00:00:46.805 --> 00:00:47.975
как вы бы отключить его.

00:00:47.975 --> 00:00:49.640
Но также, как вы можете

00:00:49.640 --> 00:00:51.790
скажите, нужно ли вам
включите эту функцию.

00:00:51.790 --> 00:00:55.600
У вас возникли проблемы, которые
эта функция предназначена для решения?

00:00:55.600 --> 00:00:58.770
Так что давайте перепрыгнем в
демо и посмотрите.

00:01:00.220 --> 00:01:02.960
Так что у меня есть блокнот открыт здесь, в

00:01:02.960 --> 00:01:05.420
Студия данных Azure
с несколькими командами.

00:01:05.420 --> 00:01:09.050
То, что мы начнем с работает
рабочая нагрузка на сервере S'L.

00:01:09.050 --> 00:01:14.315
2019 без включения памяти
Оптимизированная функция метаданных TempDB

00:01:14.315 --> 00:01:15.560
и мы постараемся взглянуть на

00:01:15.560 --> 00:01:17.930
это утверждение, что
может произойти в TempDB.

00:01:17.930 --> 00:01:21.050
Так что первое, что я
собирается сделать, это начать

00:01:21.050 --> 00:01:24.170
монитор производительности
сбор и сбор

00:01:24.170 --> 00:01:26.120
несколько различных
счетчики, которые дадут

00:01:26.120 --> 00:01:28.430
нам идея
выполнения рабочей нагрузки.

00:01:28.430 --> 00:01:31.955
Тогда я собираюсь использовать
Инструмент стресса O

00:01:31.955 --> 00:01:34.415
для выполнения многопоточной рабочей нагрузки.

00:01:34.415 --> 00:01:37.700
Итак, у меня восемь процессоров
на этой конкретной машине,

00:01:37.700 --> 00:01:39.950
но я бросаю 100
параллельные потоки.

00:01:39.950 --> 00:01:42.350
Так что у меня очень напряженная нагрузка

00:01:42.350 --> 00:01:44.810
здесь, и это очень
тяжелая рабочая нагрузка TempDB.

00:01:44.810 --> 00:01:47.210
Это базовая процедура хранения
что создает таблицу временных топоров,

00:01:47.210 --> 00:01:48.360
положить некоторые данные в него,

00:01:48.360 --> 00:01:49.805
а затем выбирает из него.

00:01:49.805 --> 00:01:52.200
Таким образом, вы можете увидеть здесь, в Perf человек.

00:01:52.200 --> 00:01:54.090
У меня есть некоторые веса в прогрессе,

00:01:54.090 --> 00:01:55.740
страница защелки весов в прогрессе.

00:01:55.740 --> 00:01:58.895
У меня также есть среднее время ожидания

00:01:58.895 --> 00:02:00.380
перечисленных здесь, в Perf человек, а также.

00:02:00.380 --> 00:02:02.390
Таким образом, вы можете видеть, что у меня есть
пейджированные веса защелки

00:02:02.390 --> 00:02:04.775
происходит, пока я
работает эта рабочая нагрузка.

00:02:04.775 --> 00:02:07.640
Это не редкость с
интенсивной рабочей нагрузки.

00:02:07.640 --> 00:02:11.580
Вопрос в том, что
эти страницы защелки весов от?

00:02:11.580 --> 00:02:12.770
Мы не знаем обязательно.

00:02:12.770 --> 00:02:14.405
Они могут быть из
базы данных пользователя.

00:02:14.405 --> 00:02:16.430
Они могут быть из TempDB.

00:02:16.430 --> 00:02:18.740
Мы действительно не знаем, просто
глядя на производительность

00:02:18.740 --> 00:02:21.620
контролировать, где эти страницы защелки
веса приходят от.

00:02:21.620 --> 00:02:23.210
Таким образом, мы хотим, чтобы вернуться к

00:02:23.210 --> 00:02:25.850
Студия данных Azure и взгляните на

00:02:25.850 --> 00:02:27.110
сценарий, который может помочь нам

00:02:27.110 --> 00:02:30.880
определить, где эти страницы
защелки весы приходят от.

00:02:30.880 --> 00:02:32.230
Похоже, моя рабочая нагрузка закончена.

00:02:32.230 --> 00:02:34.190
Так что я просто собираюсь пнуть его
отступить снова, так что мы

00:02:34.190 --> 00:02:36.925
может посмотреть на эту студию данных Azure.

00:02:36.925 --> 00:02:40.090
Так что давайте вернемся сюда.

00:02:42.130 --> 00:02:47.135
Я займусь этим запросом
которые у меня в центре внимания.

00:02:47.135 --> 00:02:51.740
Что делает этот запрос
глядя на все запросы от

00:02:51.740 --> 00:02:56.510
DM точный запрос, который
тип веса, как страница,

00:02:56.510 --> 00:03:00.335
смысл какой-то
страница защелки вес.

00:03:00.335 --> 00:03:04.010
Что я вижу в результатах
Вот что я на самом деле есть

00:03:04.010 --> 00:03:07.295
несколько сессий, которые
ожидания на странице защелки.

00:03:07.295 --> 00:03:09.305
Если я посмотрю весовой ресурс,

00:03:09.305 --> 00:03:11.990
Я могу сказать только по весу
ресурс, в который они находятся

00:03:11.990 --> 00:03:15.905
TempDB, потому что вес
ресурс здесь 2:1:1:20.

00:03:15.905 --> 00:03:17.420
Два идентификатора базы данных,

00:03:17.420 --> 00:03:18.665
два, который является TempDB.

00:03:18.665 --> 00:03:23.570
Один из них файл номер 1 и
затем 120 — это номер страницы.

00:03:23.570 --> 00:03:25.325
Так что я могу сказать, что это в TempDB.

00:03:25.325 --> 00:03:30.395
Но если я использую эту новую функцию
называется информация о странице DMDB,

00:03:30.395 --> 00:03:34.039
что это позволяет мне делать
это взять этот ресурс страницы

00:03:34.039 --> 00:03:38.330
и взломать его открытым и увидеть
что именно на этой странице.

00:03:38.330 --> 00:03:41.355
Таким образом, с этой функции информации dMDB страницы,

00:03:41.355 --> 00:03:44.150
Я получаю этот объект
имя, и вы можете видеть

00:03:44.150 --> 00:03:46.810
здесь, что имя объекта
является sys схемы объектов,

00:03:46.810 --> 00:03:48.095
которая представляет собой системную таблицу.

00:03:48.095 --> 00:03:50.944
Так вот что TempDB
утверждение метаданных

00:03:50.944 --> 00:03:52.685
о чем мы говорили.

00:03:52.685 --> 00:03:54.754
В этом и заключается проблема

00:03:54.754 --> 00:03:58.220
что память Оптимизированная TempDB
метаданные были введены для решения.

00:03:58.220 --> 00:03:59.960
Итак, давайте вернемся к
наше командное окно.

00:03:59.960 --> 00:04:01.115
Мы видим, что все закончилось.

00:04:01.115 --> 00:04:02.450
Оба раза он выполнил,

00:04:02.450 --> 00:04:06.005
это заняло около 52 секунд
для выполнения рабочей нагрузки.

00:04:06.005 --> 00:04:09.675
Мы можем, конечно, увидеть страницу
защелка весов происходит.

00:04:09.675 --> 00:04:12.300
Мы можем видеть партию
запросы в секунду,

00:04:12.300 --> 00:04:14.100
которые долива на,

00:04:14.100 --> 00:04:18.225
Давайте посмотрим здесь, около 350 максимум.

00:04:18.225 --> 00:04:20.210
Так что это без
функция включена.

00:04:20.210 --> 00:04:22.265
Так что давайте идти вперед и
включить функцию.

00:04:22.265 --> 00:04:23.795
Для того, чтобы сделать это,

00:04:23.795 --> 00:04:25.925
мы должны включить функцию в

00:04:25.925 --> 00:04:29.090
Сервер S'L и нам также необходимо
перезапустить сервер.

00:04:29.090 --> 00:04:34.250
Эта изменяет конфигурацию сервера
команда здесь требует перезагрузки.

00:04:34.250 --> 00:04:38.875
Так что мы собираемся установить, что память
Оптимизированные метаданные TempDB на.

00:04:38.875 --> 00:04:43.540
Тогда я пойду вперед и
перезапустить сервер.

00:04:44.360 --> 00:04:48.025
И как только я это сделаю,

00:04:48.025 --> 00:04:50.810
Я смогу вернуться

00:04:50.810 --> 00:04:54.155
в студию данных Azure и
запустить другую команду,

00:04:54.155 --> 00:04:57.470
выбрать свойство сервера
команда, чтобы увидеть, если

00:04:57.470 --> 00:05:01.160
Оптимизированная память TempDB
функция метаданных.

00:05:01.160 --> 00:05:03.265
Итак, давайте запустим эту команду.

00:05:03.265 --> 00:05:07.245
Вы можете увидеть его выполненным
и функция в настоящее время.

00:05:07.245 --> 00:05:10.565
Это один. Так что давайте идти вперед
и запустить нашу рабочую нагрузку снова.

00:05:10.565 --> 00:05:13.470
Начнем с Перфа.

00:05:16.490 --> 00:05:19.350
Давайте начнем нашу рабочую нагрузку еще раз.

00:05:19.350 --> 00:05:20.775
Те же точные рабочие нагрузки.

00:05:20.775 --> 00:05:24.130
Та же процедура хранения, 100 потоков.

00:05:24.130 --> 00:05:27.080
Вы можете заметить что-то
разные в Perf человек сразу.

00:05:27.080 --> 00:05:29.900
Прежде всего, пакетные запросы
в секунду гораздо выше.

00:05:29.900 --> 00:05:34.520
Мы собираемся до более чем 500.

00:05:34.520 --> 00:05:36.320
Это может даже пойти немного выше.

00:05:36.320 --> 00:05:37.580
Я позволю этому побегать какое-то время,

00:05:37.580 --> 00:05:40.790
но и обратите внимание на эти страницы
защелки веса исчезли.

00:05:40.790 --> 00:05:42.605
Нет больше веса защелки страницы.

00:05:42.605 --> 00:05:45.740
Если мы вернемся к данным Azure
Студия и я запускаем эту команду

00:05:45.740 --> 00:05:48.990
снова посмотреть на сессии.

00:05:48.990 --> 00:05:52.310
Обратите внимание, что сеансов нет
которые ждут на странице защелки.

00:05:52.310 --> 00:05:55.865
Мы полностью устранили
вес защелки страницы.

00:05:55.865 --> 00:05:57.590
Если я вернусь к Перфу,

00:05:57.590 --> 00:06:00.005
Да, моя рабочая нагрузка уже закончена.

00:06:00.005 --> 00:06:02.990
Таким образом, вы можете видеть, что я
улучшенная пропускная часть.

00:06:02.990 --> 00:06:05.675
Я устранила эти
страница защелки весов.

00:06:05.675 --> 00:06:07.580
Если я приду к своей рабочей нагрузке,

00:06:07.580 --> 00:06:10.130
теперь она завершена в 35 секунд

00:06:10.130 --> 00:06:13.760
по сравнению с 52 секунд
без функции.

00:06:13.760 --> 00:06:19.220
Так что эта функция предназначена для
чтобы помочь масштабировать

00:06:19.220 --> 00:06:23.240
ваш тяжелый TempDB
спорные рабочие нагрузки

00:06:23.240 --> 00:06:25.400
без каких-либо
код вообще меняется.

00:06:25.400 --> 00:06:28.085
Вы просто включите конфигурацию,

00:06:28.085 --> 00:06:31.640
перезапустить сервер, а затем вы
может сразу же улучшить

00:06:31.640 --> 00:06:33.770
пропускной толик и меньше
страница защелки весов

00:06:33.770 --> 00:06:36.320
на спорных рабочих нагрузках TempDB.

00:06:36.320 --> 00:06:38.300
Так что я надеюсь, что поможет вам узнать

00:06:38.300 --> 00:06:40.790
немного больше о
особенность, как вы будете использовать его,

00:06:40.790 --> 00:06:42.860
как вы знаете, является ли
Вы должны включить его

00:06:42.860 --> 00:06:45.020
или нет, и получает вас немного больше

00:06:45.020 --> 00:06:46.970
возбужденных по поводу улучшений
, которые приходят в

00:06:46.970 --> 00:06:49.610
Большое спасибо.

00:06:49.610 --> 00:07:04.210
(МУЗЫКА)