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
SQL Server 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
그것을 다시 가져 오는 것은
뭔가 DBA,

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
다시 하는 것은 모든 데이터 변경 사항입니다.

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
그래서 그 슬로그에 기록 얻을.

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
그래서 슬로그에서 다시,

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
복구를 수행하는 것은 0 초였다.

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
1분 반에서 이동한 후,

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 SQL 데이터베이스를 사용하면

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
SQL Server 데이터베이스의 경우

00:06:26.940 --> 00:06:29.060
기본적으로 꺼져 있습니다.

00:06:29.060 --> 00:06:31.610
범위에 대한 약간의 오버헤드

00:06:31.610 --> 00:06:35.880
1~5%의
버전을 추적할 수 있습니다.

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
MySQL 서버가

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
[음악]