WEBVTT

00:00:00.000 --> 00:00:01.830
>> SQL Server 2019는

00:00:01.830 --> 00:00:04.995
라는 리눅스에 대 한 새로운 기능
영구 로그 버퍼입니다.

00:00:04.995 --> 00:00:06.960
그것은 전에 윈도우에 사용할 수 있었다,

00:00:06.960 --> 00:00:08.385
뿐만 아니라 리눅스에 요즘,

00:00:08.385 --> 00:00:10.740
제거하고, 그것은 당신이 제거하는 데 도움이
병목 현상이 발생할 수 있습니다.

00:00:10.740 --> 00:00:14.130
로그를 기다리는 동안 발생합니다.
디스크에 두 개의 플러시를 버퍼링합니다.

00:00:14.130 --> 00:00:18.300
브라이언은 우리 모두에게 여기에 있다
데이터 노출에 대해 오늘.

00:00:18.300 --> 00:00:29.040
[음악]

00:00:29.040 --> 00:00:32.115
다른 사람에게 오신 것을 환영합니다.
데이터 노출의 에피소드.

00:00:32.115 --> 00:00:35.220
나는 당신의 호스트 제로엔이고,
오늘은 나와 함께 브라이언이

00:00:35.220 --> 00:00:38.460
지속적 에 대해 이야기하기
SQL 2019에서 버퍼를 기록합니다.

00:00:38.460 --> 00:00:40.230
안녕하세요, 브라이언, 쇼에 오신 것을 환영합니다.

00:00:40.230 --> 00:00:42.195
안녕하세요, 제로엔. 감사합니다.

00:00:42.195 --> 00:00:46.045
>> 그래서 우리는 무엇을 이야기할 것인가?
영구 긴 버퍼에 대해?

00:00:46.045 --> 00:00:47.160
>> 예. 그래서-

00:00:47.160 --> 00:00:47.685
>> 그게 뭐야?

00:00:47.685 --> 00:00:50.400
>> 그래서 영구 로그
버퍼는 무엇 중 하나입니다

00:00:50.400 --> 00:00:53.325
우리는 인메모리라고 부릅니다.
데이터베이스 피쳐 패밀리,

00:00:53.325 --> 00:00:55.965
인메모리 OLTP,

00:00:55.965 --> 00:00:59.265
영구 로그 버퍼
오늘은 시연하겠습니다.

00:00:59.265 --> 00:01:01.845
로그 캐싱의 꼬리라고도 합니다.

00:01:01.845 --> 00:01:05.040
데이터 및 로그 파일
리눅스의 깨달음,

00:01:05.040 --> 00:01:07.470
하이브리드 버퍼 풀에서
리눅스와 윈도우,

00:01:07.470 --> 00:01:09.870
및 메모리 최적화 TempDB 메타데이터.

00:01:09.870 --> 00:01:11.370
>> 좋아. 멋진.

00:01:11.370 --> 00:01:17.195
>> 그래서 빨리 언급할게요
영구 메모리 장치에 대해

00:01:17.195 --> 00:01:19.550
많은 사람들이
그들을 보았지만 본질적으로

00:01:19.550 --> 00:01:21.730
이러한 것들은 귀하가

00:01:21.730 --> 00:01:26.275
서버에 피드를
다른 용량으로 제공됩니다.

00:01:26.275 --> 00:01:30.545
한 타입의 MVDIMM-N
지속적인 메모리 기술,

00:01:30.545 --> 00:01:34.325
8, 16 또는 32가 제공됩니다.
공연 DIMM 용량,

00:01:34.325 --> 00:01:36.980
그리고 최신 인텔이 얻은

00:01:36.980 --> 00:01:41.150
DC 영구 메모리가 들어옵니다.
128의 훨씬 더 높은 용량,

00:01:41.150 --> 00:01:44.810
256기가바이트 또는 512기가바이트 DIMM.

00:01:44.810 --> 00:01:46.820
>> 그게 전부입니다.
영구 메모리. 와우.

00:01:46.820 --> 00:01:48.060
>> 예. 그래서 당신은 할 수 있습니다,

00:01:48.060 --> 00:01:49.290
네이트 소켓 서버에서

00:01:49.290 --> 00:01:52.370
최대 24개까지 지원할 수 있습니다.
테라바이트 의 영구 메모리.

00:01:52.370 --> 00:01:53.750
>> 나는 모든 잠금을 해제 할 수 있습니다

00:01:53.750 --> 00:01:55.970
이 끈질긴
로그 버퍼, 오른쪽?

00:01:55.970 --> 00:01:56.570
>> 정답입니다.

00:01:56.570 --> 00:01:57.680
>> 와우.

00:01:57.680 --> 00:02:00.110
>> 영구 로그
버퍼는

00:02:00.110 --> 00:02:02.075
특정 사용 사례 해결

00:02:02.075 --> 00:02:07.400
감속을 발생시키는 위치
또는 워크로드에서 대기,

00:02:07.400 --> 00:02:12.385
로그 버퍼를 기다리는 중입니다.
디스크로 플러시할 메모리에 있습니다.

00:02:12.385 --> 00:02:13.005
>> 좋아.

00:02:13.005 --> 00:02:16.114
>> 그래서 그것을 사용
영구 메모리 장치

00:02:16.114 --> 00:02:19.355
그것은 일단 그것을 알고
해당 장치에 기록된

00:02:19.355 --> 00:02:21.650
필요하지 않다는 것을
플러시를 기다립니다.

00:02:21.650 --> 00:02:24.270
이미 켜져 있기 때문에
영구 장치입니다.

00:02:24.270 --> 00:02:26.195
>> 그러면 장치가
나머지는 알아서.

00:02:26.195 --> 00:02:28.835
>> 예, 장치는
그런 다음 나머지를 돌봐

00:02:28.835 --> 00:02:31.730
당신은 본질적으로 수행하는 동안
워크로드와 함께 할 수 있습니다.

00:02:31.730 --> 00:02:32.180
>> 그렇습니다.

00:02:32.180 --> 00:02:35.585
>> 그래서 당신이 설정하는 경우
이러한 장치는 Windows에서

00:02:35.585 --> 00:02:41.600
우리는 몇 가지 기본 권장 사항이
메모리에 페이지를 잠그고,

00:02:41.600 --> 00:02:44.150
두 메가바이트를 사용합니다.
할당 단위 크기

00:02:44.150 --> 00:02:46.760
NTFS에 대한 기본값이 아닙니다.

00:02:46.760 --> 00:02:47.180
>> 좋아.

00:02:47.180 --> 00:02:49.715
또한 다음을 수행해야 합니다.
이 플래그 DAX를 설정합니다.

00:02:49.715 --> 00:02:51.920
그래서 DAX는 정말 우리가 할 수있는 것입니다

00:02:51.920 --> 00:02:55.280
영구 메모리 처리
장치 및 쓰기

00:02:55.280 --> 00:02:57.260
모든 것을 직접 건너뛰기

00:02:57.260 --> 00:02:59.795
커널 스택은

00:02:59.795 --> 00:03:03.090
일반적으로 필요
파일을 처리할 때

00:03:03.090 --> 00:03:05.145
GUI에서는 사용할 수 없습니다.

00:03:05.145 --> 00:03:07.250
그래서 당신은 사용해야합니다
이를 위해 일부 PowerShell을 사용할 수 있습니다.

00:03:07.250 --> 00:03:09.560
>> 좋아. 좋습니다. 너는 할 거야
이 작동 방식을 보여, 오른쪽?

00:03:09.560 --> 00:03:13.325
>> 예. 나는 방법을 보여줍니다
이러한 구성을 가져옵니다.

00:03:13.325 --> 00:03:16.430
또한 OS 수준의 일부
디스크 카운터

00:03:16.430 --> 00:03:19.510
같은 보고에 사용할 수 있습니다.
이러한 전송 등등,

00:03:19.510 --> 00:03:21.830
사용할 수 없을 수도 있습니다.

00:03:21.830 --> 00:03:24.200
작업할 때
영구 메모리 장치.

00:03:24.200 --> 00:03:28.865
그건 그냥 것 들 중 하나
알고 있어야 합니다.

00:03:28.865 --> 00:03:29.330
>> 물론입니다.

00:03:29.330 --> 00:03:33.575
이 새로운 장치이며 이것들은
아주 새로운 흥미 진진한 압정입니다.

00:03:33.575 --> 00:03:33.935
>> 좋아.

00:03:33.935 --> 00:03:37.565
>> 그래서 몇 가지 잡기가있을 수 있습니다
모니터링 측에서 할 수 있습니다.

00:03:37.565 --> 00:03:38.245
>> 물론입니다.

00:03:38.245 --> 00:03:42.580
>> 리눅스의 경우, 비휘발성
장치 제어

00:03:42.580 --> 00:03:45.110
는
를 사용하여 이를 구성할 수 있습니다.

00:03:45.110 --> 00:03:47.840
fsdax 모드로 설정합니다.

00:03:47.840 --> 00:03:50.795
두 메가 바이트 거 대 한 페이지 오류를 사용 하 여,

00:03:50.795 --> 00:03:53.555
블록 할당 설정
또한 2메가바이트에 이은 것입니다.

00:03:53.555 --> 00:03:56.180
우리는 XFS 또는 EXT를 지원합니다

00:03:56.180 --> 00:04:00.620
이는 두 가지가 지원됩니다.
DAX와 파일 시스템.

00:04:00.620 --> 00:04:01.295
>> 좋아.

00:04:01.295 --> 00:04:03.050
>> 그래서 영구 로그 버퍼,

00:04:03.050 --> 00:04:05.585
사용할 수 있습니다.
실제로 SQL에서

00:04:05.585 --> 00:04:10.140
SQL 2016 지금까지 윈도우전용.

00:04:10.140 --> 00:04:12.470
SQL 2019를 사용하면

00:04:12.470 --> 00:04:15.875
이 기능은 지금 사용할 수 있습니다.
리눅스뿐만 아니라 윈도우에서.

00:04:15.875 --> 00:04:18.590
아주 작은 것만 사용
용량,

00:04:18.590 --> 00:04:21.720
로그 버퍼는 20에 불과합니다.
사용자 데이터베이스당 메가바이트입니다.

00:04:21.720 --> 00:04:22.355
>> 좋아.

00:04:22.355 --> 00:04:26.330
>> 그래서 정말 하지 않습니다
엄청난 양의 용량을

00:04:26.330 --> 00:04:28.850
그리고 당신이 얻는 행동은 매우

00:04:28.850 --> 00:04:31.250
강제 와 유사
내구성이 지연됩니다.

00:04:31.250 --> 00:04:31.910
>> 좋아.

00:04:31.910 --> 00:04:34.040
그래서 다시, 당신은 기다리고 있지 않다

00:04:34.040 --> 00:04:36.890
디스크에 플러시되도록 로그 플러시

00:04:36.890 --> 00:04:40.040
하지만

00:04:40.040 --> 00:04:43.235
당신은 강제 지연 무엇을 가지고
데이터 손실에 대한 내구성.

00:04:43.235 --> 00:04:45.290
그래서 당신은 우리에게 말할 수 있습니다
조금 더 에 대해

00:04:45.290 --> 00:04:47.550
강제 지연 내구성
그 에 대 한

00:04:47.550 --> 00:04:48.615
물론,

00:04:48.615 --> 00:04:49.425
>> -그것을 인식하지 못합니까?

00:04:49.425 --> 00:04:52.095
>> 예. 사람들을 위해
익숙하지 않은 경우,

00:04:52.095 --> 00:04:53.840
이것은 본질적으로

00:04:53.840 --> 00:04:57.260
비동기 커밋
SQL Server의 메커니즘입니다.

00:04:57.260 --> 00:04:57.710
>> 좋아.

00:04:57.710 --> 00:05:01.280
>> 그래서 부부가 있다
그것을 할 수있는 방법의.

00:05:01.280 --> 00:05:03.740
하나는 허용되며, 이 경우

00:05:03.740 --> 00:05:07.190
일반 커밋
예상대로 발생합니다.

00:05:07.190 --> 00:05:08.270
당신은 플러시를 기다립니다,

00:05:08.270 --> 00:05:10.455
디스크에서 경화될 때까지 기다립니다.

00:05:10.455 --> 00:05:15.440
또는 강제 모드로 모든
커밋은 다음과 같이 행동합니다.

00:05:15.440 --> 00:05:16.000
>> 좋아.

00:05:16.000 --> 00:05:19.220
>> 그래서 허용 된


00:05:19.220 --> 00:05:22.880
이 것을 원한다면 커밋 기준
행동과 그 허용,

00:05:22.880 --> 00:05:24.935
기본값인 허용되지 않음

00:05:24.935 --> 00:05:27.425
당신이 무엇을 중요하지 않습니다
거기서 일어나지 않을 거야.

00:05:27.425 --> 00:05:27.905
>> 물론입니다.

00:05:27.905 --> 00:05:30.170
>> 그런 다음 모든 것을 강요했다.
커밋은 이러한 방식으로 행동합니다.

00:05:30.170 --> 00:05:32.285
>> 좋아. 그래서 지속적인
낮은 수준은 매우

00:05:32.285 --> 00:05:34.890
유사하지만 완전히 동일하지는 않습니다.

00:05:34.890 --> 00:05:37.215
>> 매우 유사하지만
완전히 동일하지는 않습니다.

00:05:37.215 --> 00:05:39.845
왜냐하면 우리는
영구 메모리 장치,

00:05:39.845 --> 00:05:42.965
로그 버퍼를 넣었습니다.

00:05:42.965 --> 00:05:46.640
그리고 일단 우리가 거기에 쓰면 우리는 알고
그것은 지속하고 우리는

00:05:46.640 --> 00:05:50.360
데이터 손실 위험이 없습니다.
서버 충돌이 발생할 경우,

00:05:50.360 --> 00:05:53.000
정전, 무엇이든
그 성격의,

00:05:53.000 --> 00:05:56.570
우리는 데이터에서 복구 할 수 있습니다
영구 메모리 장치입니다.

00:05:56.570 --> 00:05:57.920
>> 좋아. 멋진.

00:05:57.920 --> 00:06:00.230
>> 실제로는 아주 간단합니다.

00:06:00.230 --> 00:06:01.640
많은 사람들이 깨닫지 못합니다.

00:06:01.640 --> 00:06:04.355
로그 파일을 추가하기만 하면 됩니다.

00:06:04.355 --> 00:06:07.580
20메가바이트
영구 메모리 장치,

00:06:07.580 --> 00:06:10.370
SQL 서버는
이 장치를 인식하고,

00:06:10.370 --> 00:06:13.265
로그 버퍼로 처리합니다.

00:06:13.265 --> 00:06:14.405
>> 매우 간단합니다.

00:06:14.405 --> 00:06:15.665
>> 정말 간단합니다.

00:06:15.665 --> 00:06:16.205
>> 와우.

00:06:16.205 --> 00:06:19.550
우리가 볼 수 있듯이 > 그래,
여기에 로그 버퍼에 앉아있다

00:06:19.550 --> 00:06:23.090
우리의 스토리지 클래스 메모리
PMM은 때때로

00:06:23.090 --> 00:06:26.480
이를 스토리지 클래스라고 합니다.
메모리 및 일부 장소에서

00:06:26.480 --> 00:06:30.405
하지만 같은 일과 우리의
로그 레코드가 있습니다.

00:06:30.405 --> 00:06:31.950
그리고 내가 언급 한 바와 같이,

00:06:31.950 --> 00:06:33.200
우리는 기다릴 필요가 없습니다
그들을 통해

00:06:33.200 --> 00:06:36.365
메인으로 플러시
트랜잭션 로그 파일.

00:06:36.365 --> 00:06:37.010
>> 멋지다.

00:06:37.010 --> 00:06:41.875
>> 그래서 난 그냥 전환 할게요
여기에 내 데모에 신속하게.

00:06:41.875 --> 00:06:42.990
>> 그렇습니다.

00:06:42.990 --> 00:06:46.280
>> 먼저 그냥 보여줄게요
우리가 구성한

00:06:46.280 --> 00:06:49.310
여기에 우리의 지속적인 메모리 장치.

00:06:49.310 --> 00:06:50.945
앞서 언급했듯이, 이것들은
일반 DimM이며,

00:06:50.945 --> 00:06:53.180
장치 ID를 볼 수 있습니다.

00:06:53.180 --> 00:06:56.405
두 가지를 구성했습니다.
NUMA 노드당 하나씩 장치를 사용할 수 있습니다.

00:06:56.405 --> 00:06:56.855
>> 좋아.

00:06:56.855 --> 00:07:01.565
장치 간에 인터리브
해당 NUMA 노드의 DIMM에서

00:07:01.565 --> 00:07:05.330
그래서 이것은 추천
우리가 그것을 설정하는 말하는 방법.

00:07:05.330 --> 00:07:06.410
>> 좋아.

00:07:06.410 --> 00:07:08.950
>> 다시, 우리는 그것을 볼 수 있습니다

00:07:08.950 --> 00:07:12.920
DAX 값이 활성화됩니다.
그것은 여기에 사실로 설정,

00:07:12.920 --> 00:07:17.464
그리고 우리는 우리의 이전을 사용하려는 경우
명령줄 유형 유틸리티,

00:07:17.464 --> 00:07:21.830
우리는 단지 그 작은 얻을 수 있습니다
여기에 더 많은 정보를 비트 우리는 할 수 있습니다

00:07:21.830 --> 00:07:26.450
할당을 설정했습니다.
단위 크기에서 2메가바이트로 조정됩니다.

00:07:26.450 --> 00:07:28.640
방금 설명한 대로 >
그것은해야한다 - 예.

00:07:28.640 --> 00:07:31.505
>> 그렇습니다. 방금 보았듯이
설명하고 꽤

00:07:31.505 --> 00:07:36.185
간단한 우리는 단지 추가
내가 언급 한 바와 같이, 로그 파일,

00:07:36.185 --> 00:07:38.205
그리고 우리는 단지 만들고

00:07:38.205 --> 00:07:40.700
어떤 크기에 관계 없이
여기에 넣어 우리는 실제로 거야

00:07:40.700 --> 00:07:42.860
20메가바이트를 사용하도록 통합

00:07:42.860 --> 00:07:46.025
하지만 그냥 가서
20메가바이트가 앉아 있다고 말합니다.

00:07:46.025 --> 00:07:47.975
>> 그렇습니다. 그냥 확인합니다.

00:07:47.975 --> 00:07:50.960
>> 그래, 그리고 정말 그렇게 간단합니다.

00:07:50.960 --> 00:07:52.550
>> 와우. 좋습니다.

00:07:52.550 --> 00:07:54.200
그래서 인상적입니다.

00:07:54.200 --> 00:07:56.900
그래서 기본적으로 잠금을 해제 할 수 있습니다
이러한 모든 새로운 기술과

00:07:56.900 --> 00:07:58.580
영구 로그 버퍼

00:07:58.580 --> 00:08:00.650
아주 간단한 명령을 실행, 오른쪽?

00:08:00.650 --> 00:08:01.055
>> 그렇습니다.

00:08:01.055 --> 00:08:02.930
>> 물론입니다. 당신은 해야 해요
먼저 장치를 구성하고,

00:08:02.930 --> 00:08:05.965
그리고 그 후 완료
SQL에서 로그를 추가하면 됩니다.

00:08:05.965 --> 00:08:09.350
이 유형은

00:08:09.350 --> 00:08:12.725
기술의 정말
의 새 계층을 사용하도록 설정합니다.

00:08:12.725 --> 00:08:15.020
스토리지는 일부를 제거하는 데 도움이

00:08:15.020 --> 00:08:17.075
전통
우리가 보는 병목 현상

00:08:17.075 --> 00:08:19.640
고급 워크로드에 대한 SQL Server에서

00:08:19.640 --> 00:08:22.220
>> 맞습니다. 그래서 큰 혁신하지만

00:08:22.220 --> 00:08:24.710
그런 다음 매우 간단한 방식으로 수행

00:08:24.710 --> 00:08:26.570
사용자를 위해, 그리고
구성을 설정합니다.

00:08:26.570 --> 00:08:29.360
>> 예. 인텔리전스를 구축합니다.
SQL Server로

00:08:29.360 --> 00:08:32.240
이러한 장치 인식
그에 따라 행동하십시오.

00:08:32.240 --> 00:08:34.295
>> 그렇습니다. 아주 멋지다. 잘
공유 주셔서 감사합니다.

00:08:34.295 --> 00:08:34.895
>> 감사합니다.

00:08:34.895 --> 00:08:36.560
이것은 매우 유용했다고 생각합니다.

00:08:36.560 --> 00:08:37.910
매우 흥미로운, 적어도 나에게.

00:08:37.910 --> 00:08:40.490
나는 이것이 유용하고 희망하고
당신에게도 흥미롭습니다.

00:08:40.490 --> 00:08:43.065
구독하십시오, 좋아요,
비디오에 대한 의견,

00:08:43.065 --> 00:08:44.660
그리고 나는 다음에 당신을 볼 수 있도록 노력하겠습니다

00:08:44.660 --> 00:08:47.040
의 또 다른 에피소드
데이터 노출. 감사.

00:08:47.040 --> 00:09:01.630
[음악]