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
저는 프로그램 매니저입니다.
SQL 서버 엔지니어링 팀.

00:00:15.495 --> 00:00:17.790
오늘은 하고 싶습니다.
당신을위한 빠른 데모

00:00:17.790 --> 00:00:19.800
새로운 중 하나에
SQL Server의 기능입니다.

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
우리가 시작 하는 것은 실행
SQL Server의 워크로드입니다.

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
그래서 당신은 퍼프 남자에서 여기에서 볼 수 있습니다.

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
뿐만 아니라 퍼프 남자에 여기에 나열됩니다.

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
두 가지는 데이터베이스 ID이며,

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
여기에 개체 이름이
is 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
SQL 서버와 우리는 또한 필요
을 사용하여 서버를 다시 시작합니다.

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
당신은 뭔가를 알 수 있습니다
퍼프 맨에서 바로 다른.

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
SQL Server 2019 대단히 감사합니다.

00:06:49.610 --> 00:07:04.210
[음악]