WEBVTT

00:00:00.000 --> 00:00:09.686
[음악]

00:00:13.045 --> 00:00:15.590
따라서 모든 다른 시작
데이터 유출의 흥미로운 에피소드입니다.

00:00:15.590 --> 00:00:16.470
난 호스트 Scott Klein입니다.

00:00:16.470 --> 00:00:18.580
오늘 나와 함께 하 고
멋진 게스트를 두는.

00:00:18.580 --> 00:00:20.200
따라서 되도록 할 것 같아
자신을 소개 합니다.

00:00:20.200 --> 00:00:21.210
그렇다면 왜 안 하면 먼저 야?

00:00:21.210 --> 00:00:22.310
하 고, 우리가 수 있습니다.

00:00:22.310 --> 00:00:25.540
>> 확인, 안녕하세요
라고 해요 저는 프로그램 관리자

00:00:25.540 --> 00:00:29.540
데이터베이스 테스트 팀
데이터 그룹.

00:00:29.540 --> 00:00:30.210
>> 확인 합니다.

00:00:30.210 --> 00:00:31.520
>> Denay Kurtutlil 내 이름

00:00:31.520 --> 00:00:34.050
필자는 엔지니어링 관리자
데이터 실험 팀입니다.

00:00:34.050 --> 00:00:35.410
>> 좋은 확인을 하므로
주셔서 감사 합니다.

00:00:35.410 --> 00:00:36.330
우리의 즐거움에 는입니다.

00:00:36.330 --> 00:00:37.900
>> 만나서 반가 워, Scott.

00:00:37.900 --> 00:00:40.470
>> 따라서 우리가 많이 들 었에 대 한
여기에 어떤 사람들 보 았

00:00:40.470 --> 00:00:43.350
데이터 마이그레이션 도우미에 대 한
이러한 모든 유형의 작업 하 고입니다.

00:00:43.350 --> 00:00:46.140
들 었 적 하지만
실험 도우미: 데이터베이스

00:00:46.140 --> 00:00:47.320
>>를 새로운 이기 때문에.

00:00:47.320 --> 00:00:49.500
>> 확인, 좋아,
그런 다음 알려주시면 [웃음].

00:00:49.500 --> 00:00:51.250
이게 뭐죠?

00:00:51.250 --> 00:00:56.270
>> 이것은 실제로 아주 새로운 도구
마이그레이션할 수 있도록 도와주는 것에 대 한

00:00:57.390 --> 00:01:00.870
낮은 버전의 SQL Server
더 높은 버전입니다.

00:01:00.870 --> 00:01:02.860
따라서 적의
데이터 마이그레이션에 도움이 되 고

00:01:02.860 --> 00:01:04.910
다른 대체 도구.

00:01:04.910 --> 00:01:08.560
이것은 일종의
보완 합니다.

00:01:08.560 --> 00:01:11.160
따라서 봤 a B 테스트 /?

00:01:11.160 --> 00:01:11.740
>> 그래.

00:01:11.740 --> 00:01:14.190
>> 그러니까 A / B 테스트
데이터베이스 시스템입니다.

00:01:14.190 --> 00:01:15.440
>> 확인 합니다.
>>는 것 때문입니다.

00:01:15.440 --> 00:01:18.630
사용자가 볼 수 있듯이
대부분의 SQL 고객

00:01:18.630 --> 00:01:21.350
2008 나 아래와
원하는 2016으로 돌아가십시오.

00:01:21.350 --> 00:01:25.060
그리고 여기 오늘 그들은 구별 하 고
복잡성으로 인해 마이그레이션 및

00:01:25.060 --> 00:01:26.780
그에 관련 된 위험입니다.

00:01:26.780 --> 00:01:28.260
>> 확인 합니다.
>> 따라서이 도구 됩니다.

00:01:28.260 --> 00:01:32.400
모든 이해를 얻을 수
중단 되 고 있는 변경 또는

00:01:32.400 --> 00:01:34.730
도 성능
발생할 수 있는 문제

00:01:34.730 --> 00:01:36.760
때 새 버전으로 이동 합니다.

00:01:36.760 --> 00:01:39.720
하 고 최신 형식으로 업그레이드할 수 있습니다.
대부분에 훨씬 더 많은 버전

00:01:39.720 --> 00:01:40.497
더 많은 자신감.

00:01:40.497 --> 00:01:44.940
>> 확인 하십시오
지점에서 거 야.

00:01:44.940 --> 00:01:48.630
마이그레이션을 지원 하지 않습니다.
또한 수행의 분석

00:01:48.630 --> 00:01:50.220
주요 변경 사항 및
하는 등의 작업을?

00:01:50.220 --> 00:01:53.000
>> 길잡이 종류 마이그레이션
do의 역할 같은 것

00:01:53.000 --> 00:01:54.450
엔진 종류는 일의 분포.

00:01:54.450 --> 00:01:56.600
일은 정말
작업 부하 비교 합니다.

00:01:56.600 --> 00:01:59.430
실제로이 대 한 생각
업무 보고 하려고 합니다.

00:01:59.430 --> 00:02:00.990
생산에서 하 고

00:02:00.990 --> 00:02:03.650
작업 방법을 보려면 하려고 합니다.
새 버전을 실행 합니다.

00:02:04.670 --> 00:02:08.040
업그레이드는 이를테면 우리에 게 있어 하지만
많은 작업으로 생각해 수 있습니다.

00:02:08.040 --> 00:02:11.530
다양 한 종류의 실험을
마찬가지로 켜고 기능 서 십시오.

00:02:11.530 --> 00:02:14.500
DBA로 설정.
기능 설정 및 해제 하는 기능입니다.

00:02:14.500 --> 00:02:17.090
따라서는 일종의
일반 AB 테스트 솔루션

00:02:17.090 --> 00:02:19.920
가장 큰 시나리오 중 하나입니다.
우리를 지원 했으므로 권한입니다.

00:02:19.920 --> 00:02:21.590
에 사용 되는 동일 하지만
다른 시나리오 너무.

00:02:21.590 --> 00:02:25.508
>> 즉, DMA 실제로에
정적 코드 분석을 수행합니다.

00:02:25.508 --> 00:02:30.530
하지만 많은 않습니다 했 듯이,
더에서 작업량 비교

00:02:30.530 --> 00:02:32.240
실제 작업 부하를 사용 하 여 너무, 오른쪽.

00:02:32.240 --> 00:02:32.850
>> 확인 합니다.

00:02:32.850 --> 00:02:34.960
>> 따라서는 그 중 하나입니다.

00:02:34.960 --> 00:02:36.320
좋아, 잘 되었습니다.

00:02:36.320 --> 00:02:37.990
>> 예.
>> 거기 점을 시간 내에

00:02:37.990 --> 00:02:38.940
다른 로드 질문

00:02:38.940 --> 00:02:42.030
아마도 지정 시간에이
아마 같은 도구를 됩니까?

00:02:42.030 --> 00:02:43.440
>>는.
>> 때문에 내가 ISV 및

00:02:44.620 --> 00:02:47.570
여기이 없어 좋아
해당 도구를 실행 하려면 도구와 내가 있어.

00:02:47.570 --> 00:02:50.620
>> 예, 많이 들 었는
그에 대해 생각이 했습니다.

00:02:50.620 --> 00:02:52.440
발생
이를 병합 합니다.

00:02:52.440 --> 00:02:53.970
>> 확인 합니다.
>>의 시나리오입니다.

00:02:53.970 --> 00:02:55.959
하지만 그들은 현재
방금 도구를 구분 합니다.

00:02:57.090 --> 00:02:59.240
종류의 완료 되었지만
intervent 마이그레이션입니다.

00:02:59.240 --> 00:02:59.760
>> 예, 확인 합니다.

00:02:59.760 --> 00:03:03.900
하 고 있기 때문에 하는 것이 좋습니다.
플러시 것 처럼,

00:03:03.900 --> 00:03:07.870
그렇게 우리를 플러시이 어떻게 하면
>> 각 도구의 복잡 합니다.

00:03:07.870 --> 00:03:09.930
>> 각 도구의 복잡성

00:03:09.930 --> 00:03:12.990
위대한 있어요 지점
여기서 기본 제공, 좋은 일입니다.

00:03:12.990 --> 00:03:13.555
[혼선] 완벽 한.

00:03:13.555 --> 00:03:14.150
다음입니다.

00:03:14.150 --> 00:03:15.180
>>는 전체 의미 합니다.

00:03:15.180 --> 00:03:19.490
평균적으로 안내를 해 드리죠
여기에 수준 실험 설치

00:03:19.490 --> 00:03:21.840
데모에 들어가기 전에.

00:03:21.840 --> 00:03:25.210
따라서 시나리오가 있다고 가정해 봅시다
고객에서 위치 이동

00:03:25.210 --> 00:03:25.790
SQL 2008에 2016입니다.

00:03:25.790 --> 00:03:29.810
생산 되므로
2008 년의 환경

00:03:29.810 --> 00:03:33.592
캡처하는 것은 무엇입니까
모든 SQL 추적 합니다.

00:03:33.592 --> 00:03:34.370
>> 확인 합니다.

00:03:34.370 --> 00:03:35.210
>>와 어떤 것을

00:03:35.210 --> 00:03:38.070
테스트 환경을 사용 하는 다음
있는 두 개의 인스턴스가 있습니다.

00:03:38.070 --> 00:03:41.880
해당 SQL을 모방 하는
2008 환경입니다.

00:03:41.880 --> 00:03:44.560
2에서와 같이 잘
인스턴스는 SQL 2016

00:03:44.560 --> 00:03:47.020
대상입니다.

00:03:47.020 --> 00:03:49.220
이것은 A와
B를 논의 하 고 있습니다.

00:03:49.220 --> 00:03:53.670
따라서 DA를 사용 하
데이터베이스를 재생

00:03:53.670 --> 00:03:57.900
캡처한 모든 것을 하
이러한 두 개의 테스트 환경입니다.

00:03:57.900 --> 00:03:58.820
>> 자, 이제 되었습니다.

00:04:00.140 --> 00:04:03.960
>> 한 후 그는 비활성화
처리 하 고 추적을 분석 하 여

00:04:03.960 --> 00:04:06.380
부재 중 얻을 수 있도록
>>는 A와 B

00:04:06.380 --> 00:04:06.590
>> 확인 합니다.

00:04:06.590 --> 00:04:10.170
>>을 다음에 표시
수 있는 멋진 UI 보고서

00:04:10.170 --> 00:04:13.200
자세한 성능 포함 하 고
오류, 오류 관련 데이터.

00:04:13.200 --> 00:04:14.720
>>가 있는지 확인 합니다.
우리를 백업할 수 하겠습니다?

00:04:14.720 --> 00:04:16.770
에 대 한 사과
바보 같은 질문입니다.

00:04:16.770 --> 00:04:18.410
따라서 A 주 겠다 하 고

00:04:18.410 --> 00:04:20.360
가 2008 년 이후
>> 권한입니다.

00:04:20.360 --> 00:04:20.870
>>를 수정 합니다.

00:04:20.870 --> 00:04:22.850
>> 하려고 하는 재생
2008 다른 인스턴스에 대해

00:04:22.850 --> 00:04:23.140
>> 권한입니다.

00:04:23.140 --> 00:04:24.150
>> 물론 2016 인스턴스를?

00:04:24.150 --> 00:04:24.650
>> 하지만, 예.
>> 권한입니다.

00:04:24.650 --> 00:04:26.170
하지만 이유는 이유는.

00:04:26.170 --> 00:04:27.510
실제로 좋은 지적입니다.

00:04:27.510 --> 00:04:29.140
이유는 이유는
처치 했다.

00:04:29.140 --> 00:04:32.580
>> 일반적으로 생산에
환경으로 알고 있는 Dba 및

00:04:32.580 --> 00:04:36.540
응용 프로그램 소유자 마음에 들지 않으면 너무 많이
시스템의 성능 오버 헤드

00:04:36.540 --> 00:04:40.160
성능을 확인 하고자 하는
캡처를 설정 하 여 오버 헤드

00:04:40.160 --> 00:04:41.345
최소 생산 시스템.

00:04:41.345 --> 00:04:42.050
>> 확인 합니다.
>> 지금

00:04:42.050 --> 00:04:44.740
1 단계에서 수행할 때 우리
프로덕션에 추적 캡처

00:04:44.740 --> 00:04:47.670
시스템만 접수
추적 이벤트의 하위 집합입니다.

00:04:47.670 --> 00:04:49.650
작업 부하, 수만
필요한 것입니다.

00:04:49.650 --> 00:04:53.190
할 수 있는 물건의 나머지 부분을
프로덕션 환경에서 하지만

00:04:53.190 --> 00:04:54.330
AB 테스트를 수행할 수는 여전히

00:04:54.330 --> 00:04:56.840
사과, 사과 비교합니다.
A primes으로

00:04:56.840 --> 00:04:59.230
B는 비슷한 종류의 하드웨어
같은 구성 및 작업.

00:04:59.230 --> 00:04:59.780
>> 확인 합니다.
>> 그래.

00:04:59.780 --> 00:05:02.430
실례합니다
자신에, 오른쪽의 비교?

00:05:02.430 --> 00:05:03.970
>> 예.
>>에 베이스 레벨 형식을

00:05:03.970 --> 00:05:04.540
시나리오입니다.

00:05:04.540 --> 00:05:05.250
>> 정확 하 게.
>> 예.

00:05:05.250 --> 00:05:05.820
>> 확인 합니다.
세련 된 디자인.

00:05:05.820 --> 00:05:07.280
>> 영역에 있는 그러나 발견입니다.

00:05:07.280 --> 00:05:09.970
>> 확인, 예,
I 하에서 서 자,

00:05:09.970 --> 00:05:11.687
왜 난 다시 실행 하 고이?

00:05:11.687 --> 00:05:13.990
확인을 지키는 내가 듣고 있는 경우
다른 사용자는 요청 하는 것입니다.

00:05:13.990 --> 00:05:15.040
>> 절대적으로.
>> 거 야에 게는,

00:05:15.040 --> 00:05:17.020
필자가 안
바보 같은 질문을 합니다.

00:05:17.020 --> 00:05:19.388
분명 한 질문을
[혼선]을 지키입니다.

00:05:19.388 --> 00:05:22.285
>> 이러한 기능은 고객에 게 서 많이
했던 1.5%에 대 한 것 이므로

00:05:22.285 --> 00:05:25.648
이 작업을 수행 하는 경우 cpu 오버 헤드
생산 되는 종류의

00:05:25.648 --> 00:05:27.960
크기가 작아서 실제로 하는 경우
그래, 생각해.

00:05:27.960 --> 00:05:28.910
>> 자, 그는 장점이 있지만

00:05:28.910 --> 00:05:30.860
이 봐 었으 리라 생각 하면 됩니까
이 좋은 보고서

00:05:30.860 --> 00:05:34.470
이 봐, 여기는 어떻게
>> 오른쪽으로 이동 하려고?

00:05:34.470 --> 00:05:35.210
>>를 오른쪽입니다.

00:05:35.210 --> 00:05:36.730
>> 하 고,
데모를 선택 합니다.

00:05:36.730 --> 00:05:39.170
>> 이러한 사실은의 같은
비활성화를 입력 하면

00:05:39.170 --> 00:05:42.610
왼쪽 측면 있습니다
세 가지 기능을 참조 하십시오.

00:05:42.610 --> 00:05:44.400
캡처, 재생 및 분석 합니다.

00:05:44.400 --> 00:05:47.250
좋아, 하 고 방금 얘기
건축 하는

00:05:47.250 --> 00:05:49.060
기본적으로 이러한
세 가지 기능이 있습니다.

00:05:49.060 --> 00:05:51.200
>> 네, 이것은 내 초기
내가 하려고 2008 인스턴스

00:05:51.200 --> 00:05:51.820
데이터를 수집 합니다.

00:05:51.820 --> 00:05:53.130
>> 정확 하 게.
>> 확인, 여기를

00:05:53.130 --> 00:05:56.390
캡처에 존재 하는 경우
실제로 SQL Server 가리킬 수 있습니다.

00:05:56.390 --> 00:05:57.210
인스턴스입니다.

00:05:57.210 --> 00:05:59.150
여기 내 2008 소스입니다.

00:05:59.150 --> 00:06:02.240
얼마나 오래 합니까 지정할 수 있습니까
이 추적을 실행

00:06:02.240 --> 00:06:04.090
고 여기는 기간입니다.

00:06:04.090 --> 00:06:05.960
및 다음 최대 파일 크기입니다.

00:06:05.960 --> 00:06:08.480
일반적으로 이것은 프로 파일은
추적에 대 한 크기입니다.

00:06:08.480 --> 00:06:09.620
권장 생각은 200입니다.

00:06:09.620 --> 00:06:12.140
200으로 두면
몇 가지 특별 한 요구 사항이 아닌 경우 또는

00:06:12.140 --> 00:06:14.470
그와 같은 고
추적에 대 한 이름입니다.

00:06:14.470 --> 00:06:16.290
시작 하 고
이 되는 것을 일어나 고

00:06:16.290 --> 00:06:18.960
추적 캡처 이벤트를 발생 시킵니다.
SQL Server 2008에서

00:06:18.960 --> 00:06:20.060
>> 확인 합니다.

00:06:20.060 --> 00:06:22.620
>> 이미은 것을 여기서 알게
추적 캡처를 시작 합니다.

00:06:22.620 --> 00:06:25.800
하는 방법에 좋은 참조 해야
진행 상황을 측정 하 고

00:06:25.800 --> 00:06:26.540
그렇게 알고 있습니다.

00:06:26.540 --> 00:06:28.050
>> 확인 합니다.
>> 이제 생산 과정 이므로

00:06:28.050 --> 00:06:28.820
작업 부하 캡처입니다.

00:06:28.820 --> 00:06:30.460
60 분 동안 실행 하려는 및

00:06:30.460 --> 00:06:33.000
그런 다음 추적 해야 합니다.
끝날 때까지이.

00:06:33.000 --> 00:06:35.800
>> [웃음] 확인을 하므로
질문이 있는 경우.

00:06:35.800 --> 00:06:38.660
따라서 말이 봐, 하는
내가 바로 이동 하는, 이미 있는 경우

00:06:38.660 --> 00:06:41.730
추적 하 던 데 아마도 이미
수행할 수 있습니까 위로 당깁니다 여기에?

00:06:41.730 --> 00:06:43.040
>> 예,
다음 물건을 수행할 필요가 없습니다.

00:06:43.040 --> 00:06:44.400
다음으로 이동할 수 있습니다.
단계 하나가 있는 경우입니다.

00:06:44.400 --> 00:06:45.790
>> 자 이므로
2 단계를 시작 하 고 이동 자 수 있습니까.

00:06:45.790 --> 00:06:46.480
>> 2 단계 하 고 거기에서 이동 합니다.

00:06:46.480 --> 00:06:48.040
>> 난 계속 추적을
난 이미 캡처 했습니다.

00:06:48.040 --> 00:06:48.721
>> 예.
>> 확인 합니다.

00:06:48.721 --> 00:06:49.901
예, 할 수 있습니다 일반적으로

00:06:49.901 --> 00:06:52.811
하지만 같은 작업 부하에서 재생
다른 종류의 구성

00:06:52.811 --> 00:06:54.321
작업 하려는 경우에 그렇게 하 고입니다.
>> 자, 세련 된 디자인.

00:06:54.321 --> 00:06:55.401
>>를 이유를 항상 항상

00:06:55.401 --> 00:06:58.141
이렇게를 분리 합니다.
사람들이 캡처한 추적 하는 경우

00:06:58.141 --> 00:07:00.380
이미 돌아갈 필요가 없습니다.
-같은 내용을 다시.

00:07:00.380 --> 00:07:03.650
제공 하 고 재생할 수 또는
또는 있습니다 이죠.

00:07:03.650 --> 00:07:04.500
>> 아주 잘, 좋아, 멋지지 않습니까?

00:07:04.500 --> 00:07:05.500
아주 좋아요.

00:07:05.500 --> 00:07:09.260
따라서 2 부에서 진행 하 고
여기서는 캡처 중지

00:07:09.260 --> 00:07:12.120
두 명 이상 완전 고민
좋습니다.

00:07:12.120 --> 00:07:15.460
지금 재생 부에서 이동
여기서는 두 가지 단계

00:07:15.460 --> 00:07:19.960
첫 번째 단계는 기본적으로 재생
일종의 재생 인프라 확인 중

00:07:19.960 --> 00:07:20.090
>> 확인

00:07:20.090 --> 00:07:21.720
>>는 하나의 중요 한 점은 여기는 고

00:07:21.720 --> 00:07:23.890
이 릴리스와 함께이
세트 안

00:07:23.890 --> 00:07:26.860
재생 인프라
사용 하 여 분산된 재생

00:07:26.860 --> 00:07:28.830
이미 사용 하지 않는
SQL 설치의 일부입니다.

00:07:28.830 --> 00:07:30.920
>> 예, 분산된 재생
컨트롤러 정도 되죠입니다.

00:07:30.920 --> 00:07:31.630
>> 정확 하 게.
예를 누릅니다.

00:07:31.630 --> 00:07:33.920
따라서 않습니다 좋아요, 확인
설치 프로그램의이 시점에서.

00:07:33.920 --> 00:07:36.880
준 다음
하나의 컨트롤러 컴퓨터 및

00:07:36.880 --> 00:07:37.820
4 개의 하위 시스템 및

00:07:37.820 --> 00:07:40.390
이미 구성 되어 있습니다
오른쪽 설정에서 방법입니다.

00:07:40.390 --> 00:07:43.290
내가 언제 실행 하 고 다음에 어떤의
확인 하는 등의 종류는

00:07:43.290 --> 00:07:45.960
이 봐는 설치가 정말 꽉
액세스를 했습니다.

00:07:45.960 --> 00:07:46.840
모든 자식 및

00:07:46.840 --> 00:07:50.810
서로 게 컨트롤러
하 고 정상적으로 작동 하는 것입니다.

00:07:50.810 --> 00:07:52.880
>> 괜찮아, 그렇게
그는 봐 작업 잘 했다고 합니다.

00:07:52.880 --> 00:07:54.610
이제 때
추적을 선택 합니다.

00:07:54.610 --> 00:07:57.090
이것은 우리가 어떤
1 단계에서 캡처됩니다.

00:07:57.090 --> 00:07:58.480
>> 확인 합니다.
>>는 작업 부하를 기억 합니다.

00:07:58.480 --> 00:07:59.630
캡처입니다.

00:07:59.630 --> 00:08:01.820
>> 이것은 어디 있습니까
내가 있어 하나를 말하십시오.

00:08:01.820 --> 00:08:03.090
>> 정확 하 게 맞습니다.

00:08:03.090 --> 00:08:05.545
그냥 빼면, 해 드리죠
여기에서이 대화 상자를.

00:08:11.554 --> 00:08:14.481
저는 자동된으로 얼마나 좋을까
할 일이 아니지만 내가 그렇지 그렇게.

00:08:16.909 --> 00:08:21.120
>> 따라서 여기 하겠습니다 추적
파일을 캡처 및

00:08:21.120 --> 00:08:25.949
그런 다음 저는 물론 저장
전처리 출력 여기입니다.

00:08:25.949 --> 00:08:26.820
>> 확인 합니다.
>> 지금

00:08:26.820 --> 00:08:28.930
작업을 기본적으로
데이터 아키텍처를 재생합니다.

00:08:28.930 --> 00:08:31.870
파일을 변환
최적화 된 파일을 오른쪽입니다.

00:08:31.870 --> 00:08:35.480
그러면 실제로 전달 되 고 고
에 최적화 된 방식으로 확인

00:08:35.480 --> 00:08:39.000
추적에서 이러한 파일을 변환 합니다.
파일을 재생 파일을, 좋아.

00:08:39.000 --> 00:08:40.680
>>이 고 세 번째 단계
재생을 그다지.

00:08:40.680 --> 00:08:43.751
UI를 여기에서 볼 수 있습니다.
이 옵션을 특정

00:08:43.751 --> 00:08:45.057
데이터베이스와 [혼선]입니다.

00:08:45.057 --> 00:08:46.967
>> 이것은 있습니다 어디에,이 봐,

00:08:46.967 --> 00:08:48.850
이러한 대상으로-
>> 정확 하 게.

00:08:48.850 --> 00:08:49.450
>> 좋아.

00:08:49.450 --> 00:08:53.020
>>을 수행할 수 있는 예는
지정된 된 데이터베이스에 재생 합니다.

00:08:53.020 --> 00:08:55.950
이 시나리오에서는 그런 곳 있습니다
2008로 업그레이드 하는 16, 또는

00:08:55.950 --> 00:08:58.740
할 수 있는 용 2008 한 번 하 고
2016에 대 한 다른 시간입니다.

00:08:58.740 --> 00:09:02.021
>> 아키텍처를 기억 하는 경우
그 중 두 했습니다.

00:09:02.021 --> 00:09:04.760
A 1과
다른 하나는 B.에 있기

00:09:04.760 --> 00:09:06.610
>> 할 수 있는 동시에 나

00:09:06.610 --> 00:09:09.390
A에 대 한 실행가 고
그런 다음 B?

00:09:09.390 --> 00:09:10.970
>>는 UI에서
우리가 수행할 것 하나 한 번에.

00:09:10.970 --> 00:09:12.400
>> 한 번에 하나씩입니다.
>> 우리는 명령 지원

00:09:12.400 --> 00:09:14.770
여기서 동시에 할 수 있습니다.

00:09:14.770 --> 00:09:16.990
>> 사용자에 대 한 시작과 수 있습니다.
두 인스턴스가 모두입니다.

00:09:16.990 --> 00:09:18.010
>>를 좋은.

00:09:18.010 --> 00:09:19.080
세련 된 디자인.

00:09:19.080 --> 00:09:20.260
>> 그런 예
마지막 화면을 했습니다.

00:09:20.260 --> 00:09:21.440
없 겠 너무 멀리 떨어져 라.

00:09:21.440 --> 00:09:22.520
걸릴 것입니다.
약간의 시간입니다.

00:09:22.520 --> 00:09:24.250
따라서 시간, 관심 영역에 대 한

00:09:24.250 --> 00:09:26.690
이제 실제로 알려드릴 수 있습니다.
SQL 인스턴스에.

00:09:26.690 --> 00:09:28.440
고 말한 다음, 내 재생을 중지 합니다.

00:09:28.440 --> 00:09:29.540
>> 확인 합니다.
>> 한 다음 파일을 메시지를 재생 합니다.

00:09:29.540 --> 00:09:30.610
다음의 진행 상황을 볼 수 있습니다.

00:09:30.610 --> 00:09:32.580
진행 상황을 본 것 처럼
첫 번째.

00:09:32.580 --> 00:09:33.340
>> I는 어디에, 않기 때문에

00:09:33.340 --> 00:09:36.360
여기 내 2008 인스턴스는
[들리지 않음] 정확 하 게.

00:09:36.360 --> 00:09:39.100
>> 한 다음, 완료 되 면,
이제 난에 대해 실행 내 2008

00:09:39.100 --> 00:09:40.610
내 2016 인스턴스입니다.

00:09:40.610 --> 00:09:41.170
>> 정확 하 게.

00:09:41.170 --> 00:09:42.080
>> 확인 합니다.
>>는 정확 합니다.

00:09:42.080 --> 00:09:43.700
좋아, 하 고
다음 작업을 완료 하는 경우에 보이지

00:09:43.700 --> 00:09:44.860
출력 결과?

00:09:44.860 --> 00:09:47.700
>> 두 추적 해야 이제
둘 다에서 캡처한입니다 대체 됩니다.

00:09:47.700 --> 00:09:50.190
>> 확인 합니다.
>> 고 세 번째 단계를 수행 합니다.

00:09:50.190 --> 00:09:52.310
여기 새 분석을 해야합니다.

00:09:52.310 --> 00:09:55.460
경우 입력 하지 않기 때문에 있습니다
원본 서버에서 추적을 드리기

00:09:55.460 --> 00:09:57.560
대상 서버에서 추적 하 고 있습니다.

00:09:57.560 --> 00:10:00.690
이 제공 하는
2008 고 2016 추적 파일입니다.

00:10:00.690 --> 00:10:06.076
>>는 두
아니라 소스 하나, 둘입니다.

00:10:06.076 --> 00:10:07.064
>>는 A 소수와 B는

00:10:07.064 --> 00:10:07.825
>>는 B 최적을 확인 합니다.

00:10:07.825 --> 00:10:08.411
>> 권한입니다.

00:10:08.411 --> 00:10:08.971
>> 취약점입니다.

00:10:08.971 --> 00:10:12.258
>> 예를 한 다음 제공 된
SQL Server 차례로

00:10:12.258 --> 00:10:15.340
인스턴스를
분석 보고서를에 놓습니다.

00:10:15.340 --> 00:10:17.170
한 예는 데이터를 가져옵니다.

00:10:17.170 --> 00:10:18.670
우리는 표시를 하겠습니다.

00:10:18.670 --> 00:10:21.099
같은 구성의
수행한 작업을 테스트 합니다.

00:10:31.008 --> 00:10:34.260
그렇다면 어떻게 하는 것은이
기존 보고서를 봅니다.

00:10:34.260 --> 00:10:36.860
모든 보고서는
전에 생성 되었습니다.

00:10:36.860 --> 00:10:39.067
그 중 한 것은 무엇입니까
보여, 다음 이동 하는 것

00:10:39.067 --> 00:10:42.481
이 수 있는 통찰력
비교 작업을 가져옵니다.

00:10:42.481 --> 00:10:45.026
>> 예, 묻는 것 같아
시작할 때 해당 권한

00:10:45.026 --> 00:10:45.851
>> 내가 말을 하려고 했던

00:10:45.851 --> 00:10:47.920
보고서를 저장할 수 있습니다
해당 유형의 기능이 있지만입니다.

00:10:47.920 --> 00:10:48.623
>> 정확 하 게.

00:10:48.623 --> 00:10:49.138
>> 확인 합니다.

00:10:49.138 --> 00:10:50.652
>> DB 인스턴스를 가리키는 경우

00:10:50.652 --> 00:10:52.900
모든 끌어오기 됩니다.
일 냈 구나입니다.

00:10:52.900 --> 00:10:55.800
>> 등에 모두 발견 되 면
보고서를 사용 하 여 만든

00:10:55.800 --> 00:10:58.800
이름과 접두사 분석
이전에 부여한

00:10:58.800 --> 00:10:59.960
화면에 표시 된 기능을 통해 자동에.

00:10:59.960 --> 00:11:03.030
따라서 모든 것을 끌어 됩니다.
해당 데이터베이스.

00:11:03.030 --> 00:11:03.530
>> 확인 합니다.
세련 된 디자인.

00:11:04.640 --> 00:11:08.390
여기에서는 먼저
작업 부하를 나타냅니다.

00:11:08.390 --> 00:11:10.490
이제는 두 종류의
balls, 파란 공 하 고

00:11:10.490 --> 00:11:11.630
녹색 공입니다.

00:11:11.630 --> 00:11:16.160
우리는 블루 볼 평균 쿼리
처음으로 본

00:11:16.160 --> 00:11:19.250
녹색 공 쿼리를 의미 하는 동안
이전에 살펴본 하 고

00:11:19.250 --> 00:11:21.240
이미 평가 했습니다 했습니다.

00:11:21.240 --> 00:11:23.590
종류의 표시를 어떻게 하면
작업 진행 되 고

00:11:23.590 --> 00:11:25.670
이것은 일종의
테스트 작업 부하입니다.

00:11:25.670 --> 00:11:27.040
시간이 경과 하면서 볼

00:11:27.040 --> 00:11:29.910
대부분의 쿼리가
이미 평가 됩니다.

00:11:29.910 --> 00:11:34.380
목적은 한 통찰력을 제공 하므로
이 봐, 들은 잡 같은 좋은

00:11:34.380 --> 00:11:37.980
작업의 양 또는
스틸 작업 부하 상황 입니까?

00:11:37.980 --> 00:11:39.120
>> 예.
>> 캡처에 필요한 무엇입니까

00:11:39.120 --> 00:11:39.790
약간 더 긴?

00:11:39.790 --> 00:11:42.370
통찰력의 종류 때문에
이와 같은이 작업을 제공 하고자 합니다.

00:11:42.370 --> 00:11:43.150
표현입니다.

00:11:43.150 --> 00:11:44.870
>> 확인, 바로,

00:11:44.870 --> 00:11:46.810
충분히 캡처한 있습니까
>> 정확 하 게.

00:11:46.810 --> 00:11:48.590
>> 정보 수
좋은 결정을

00:11:48.590 --> 00:11:50.470
>>를 수정 합니다.
>>는 이러한 도움말 사람들

00:11:50.470 --> 00:11:52.530
마찬가지로 금융 기관에 대 한

00:11:52.530 --> 00:11:55.540
예제 선택에 있는 것 처럼
시간에 같은 3 5 오전입니다.

00:11:55.540 --> 00:11:56.140
>> 확인 합니다.

00:11:56.140 --> 00:11:56.980
>> 하의 또는

00:11:56.980 --> 00:11:59.270
단지 라 아웃 처럼 I
어떤 픽업 시간 알 수 없습니다.

00:11:59.270 --> 00:11:59.950
>> 권한입니다.
>> 하지만

00:11:59.950 --> 00:12:02.750
즉, 하고자 하는 대상에
실제 작업 부하를 보려면

00:12:02.750 --> 00:12:03.470
표현입니다.

00:12:03.470 --> 00:12:05.250
>> 확인 하십시오
우리가 우리가 여기에서 설명 하는 것 같습니다.

00:12:05.250 --> 00:12:05.800
>> 예.
>> 인가요?

00:12:05.800 --> 00:12:06.310
>>를 수정 합니다.

00:12:06.310 --> 00:12:08.020
>> 확인 합니다.
>>이 통찰력 도움이 됩니다 이므로

00:12:09.800 --> 00:12:10.910
적절 한 시기에 캡처하십시오.

00:12:10.910 --> 00:12:11.980
>> 자, 이제 되었습니다.

00:12:11.980 --> 00:12:12.950
>> 예.

00:12:12.950 --> 00:12:15.410
>> 고 보이는 것입니다.

00:12:15.410 --> 00:12:19.200
한 신뢰도 분석 제공
어떤 쿼리 오류 출력의

00:12:19.200 --> 00:12:22.060
어떤 쿼리 저하 쿼리 내용
향상 하 고는 같이

00:12:22.060 --> 00:12:25.410
두는 실험 수행
SQL Server 여러 버전입니다.

00:12:25.410 --> 00:12:27.140
>> 지금, 여기,이 블록
빨간 블록

00:12:27.140 --> 00:12:30.000
실제로 쿼리를 보여 줍니다.
이 오류 아웃.

00:12:30.000 --> 00:12:30.998
>> 있으므로 들어가기입니다.

00:12:30.998 --> 00:12:35.750
>> 대기을 할 수 있습니다.
묻는 다른 확실 한 또는

00:12:35.750 --> 00:12:37.800
아마 분명 하지 질문입니다.

00:12:37.800 --> 00:12:38.360
>> 있는지 확인 합니다.
>> 따라서

00:12:38.360 --> 00:12:40.850
16 SQL에 대 한 테스트를 실행 했습니다.

00:12:40.850 --> 00:12:41.920
>> 권한입니다.

00:12:41.920 --> 00:12:44.290
>> 따라서
그러니까 쿼리 프로시저를 실행 합니다.

00:12:44.290 --> 00:12:47.910
따라서 쿼리는 빨간색의 말
[INAUDIBLE]에서 제공 하는

00:12:47.910 --> 00:12:49.860
2008 2016에 오류가 발생 했습니다.

00:12:49.860 --> 00:12:51.781
>> 확인 합니다.
[혼선] 2 가지

00:12:51.781 --> 00:12:53.635
오른쪽 세 가지?

00:12:53.635 --> 00:12:57.160
하나는 작동 하는 쿼리
2008 있지만 2016에 오류.

00:12:57.160 --> 00:12:57.900
>> 확인 합니다.

00:12:57.900 --> 00:13:00.660
>> 하나는, 및
경우에 작동 하는 것

00:13:00.660 --> 00:13:03.840
2008 년에 제대로 작동 하지
하지만 2016에서 정상적으로 작동을 시작 합니다.

00:13:03.840 --> 00:13:05.150
그건 가능한 너무입니다.

00:13:05.150 --> 00:13:05.680
>> 예.

00:13:05.680 --> 00:13:07.490
>> 따라서 우리 종류의 모두 보기
조합은 여기

00:13:07.490 --> 00:13:08.600
>> 확인 합니다.

00:13:08.600 --> 00:13:10.470
예를
여기 오른쪽에 보면 예제?

00:13:10.470 --> 00:13:13.060
다음 세 가지는
기존 오류, 새로운 오류 및

00:13:13.060 --> 00:13:13.990
오류를 해결 합니다.

00:13:13.990 --> 00:13:15.750
>> 확인 합니다.
>> 기존 오류는이 알고

00:13:15.750 --> 00:13:19.290
오류 2008에서 우리가 하 고
일종의 2016에서 볼 수 있습니다.

00:13:19.290 --> 00:13:20.770
>> 확인 합니다.
>> 새 것과 같은 오류는

00:13:20.770 --> 00:13:23.054
이 하지만이 보지 않 았
지금 보게 것에서 2016.

00:13:23.054 --> 00:13:24.552
>> 실제 변경 합니다.

00:13:24.552 --> 00:13:27.540
>> 일부 변경 및 일부 키워드가 없습니다
지원 및 물건 좋아입니다.

00:13:27.540 --> 00:13:29.800
오류를 해결 하 고
2008 년에 일

00:13:29.800 --> 00:13:31.480
erring 아웃 하지만 확실히 이해 하셨나요 2016에서 해결 되었습니다.

00:13:31.480 --> 00:13:34.980
>> 확인 합니다.
>> 둘 다 이기 때문 수행

00:13:34.980 --> 00:13:38.340
예제를 보면 몇 가지
오류를 바로 바로 계산 해야 합니다.

00:13:38.340 --> 00:13:40.905
계산을 지 원하는 중지 하는 것
키보드에서 멋진 알려 줍니다.

00:13:40.905 --> 00:13:41.715
단어 하나에 12입니다.

00:13:41.715 --> 00:13:45.765
>>에 최소 DMA 종류의 알려줍니다.
이제 알게 되는 문제 같습니다.

00:13:45.765 --> 00:13:46.465
>> 예, 정확 하 게.

00:13:46.465 --> 00:13:49.115
종류의 알려줍니다 때문
작업 부하의 관점입니다.

00:13:49.115 --> 00:13:51.995
드릴 다운을 같이 볼 수 있습니다.
편집기에 대 한 자세한 내용은 및

00:13:51.995 --> 00:13:53.905
같이.

00:13:53.905 --> 00:13:58.525
기본 페이지를 다시 제공 하 고

00:13:58.525 --> 00:14:01.550
올바른 쿼리를
제 말은.

00:14:01.550 --> 00:14:03.082
또한 DBA에 그렇게 하 고

00:14:03.082 --> 00:14:05.980
응용 프로그램을 확인 하 려
내 작업 부하를 실행에 미치는 영향이입니다.

00:14:05.980 --> 00:14:09.690
얼마나 성능 적중
이렇게 함으로써 자르는?

00:14:09.690 --> 00:14:11.900
따라서이 보기 종류를 제공.

00:14:11.900 --> 00:14:16.180
쿼리를 확인할 수 있도록
AB의 평균 기간 및

00:14:16.180 --> 00:14:18.310
기간 차이 및
프레젠테이션의 차이입니다.

00:14:18.310 --> 00:14:20.370
뭔가 선택의
중요 한 약간.

00:14:22.180 --> 00:14:23.020
다음 중 하나를 볼.

00:14:25.620 --> 00:14:27.220
우리가 아래로, 구축
쿼리에서 여기.

00:14:27.220 --> 00:14:30.140
한 가지 명심할 것은
쿼리를 정규화 됩니다.

00:14:30.140 --> 00:14:31.620
매개 변수 라인 상태가 됩니다.

00:14:31.620 --> 00:14:34.540
우리는 일종의 확인 하는

00:14:34.540 --> 00:14:37.710
동일한 쿼리 해시
없는 매개 변수입니다.

00:14:38.960 --> 00:14:42.050
몇 번 지시할 것
가져온 보안 A와 B, 평균

00:14:42.050 --> 00:14:45.710
기간, Cpu, 읽기,
쓰기 및 등입니다.

00:14:45.710 --> 00:14:49.430
또한 파악 하
쿼리 계획의 비교 합니다.

00:14:49.430 --> 00:14:52.300
이제이 부분에 대 한 우리
쿼리 계획 컴파일 했습니다.

00:14:52.300 --> 00:14:53.520
>> 확인 합니다.

00:14:53.520 --> 00:14:56.870
>>에서 컴파일된 있지만
쿼리 계획을 볼 수 있습니다 없습니다

00:14:56.870 --> 00:15:00.570
방법에 차이가
컴파일된 쿼리 계획은.

00:15:00.570 --> 00:15:07.140
예를 들어 지금 a에 대 한 표시의
평균 시간 47,847입니다.

00:15:07.140 --> 00:15:08.545
고 B에 대 한 것은 훨씬 더.

00:15:08.545 --> 00:15:10.490
>> 권한입니다.
>> 컴파일 신용 계획입니다

00:15:10.490 --> 00:15:13.780
실제 실행 데이터
또한 같은 것을 말하십시오.

00:15:13.780 --> 00:15:16.790
여기에서 브라우저에서 볼 경우
기간을 확인할 수 있습니다.

00:15:16.790 --> 00:15:19.620
B의 점선
위쪽에 파란색 줄

00:15:19.620 --> 00:15:23.345
비 점 보다 훨씬 높은
파란색 선이 굵은 파란색 선은입니다.

00:15:23.345 --> 00:15:24.560
>> 확인 합니다.
>> 고는 볼 수 있습니다.

00:15:24.560 --> 00:15:26.640
또한 CPU 사용량 차이입니다.

00:15:26.640 --> 00:15:28.440
B의 실제로 사용 하 고
좀 더 많은 Cpu.

00:15:28.440 --> 00:15:28.970
이 신용에 대 한

00:15:28.970 --> 00:15:31.550
성능에서 차이 알
따라 저하 합니다.

00:15:31.550 --> 00:15:32.050
>> 확인 합니다.
>> 예.

00:15:32.050 --> 00:15:32.730
이 더

00:15:32.730 --> 00:15:36.710
탄약 고가 이라고 생각 해요,
그 이유를 파악 하기

00:15:36.710 --> 00:15:37.870
degredated 이야기,
>> 예.

00:15:37.870 --> 00:15:38.995
>>를 정확 하 고 올바른.

00:15:38.995 --> 00:15:41.920
>> 종류의 흥미로운 지키
원인을 알고 몇-했습니다

00:15:41.920 --> 00:15:44.430
여기에 Bob 워드 지나가 네
SQL16 단지 빠릅니다.

00:15:44.430 --> 00:15:45.220
이에 감사 드리며 고

00:15:45.220 --> 00:15:47.090
음, 저는
>> 예.

00:15:47.090 --> 00:15:49.330
>> 하지 않습니다 경우에
>> 예, 정확 하 게.

00:15:49.330 --> 00:15:50.010
어떻게 된 것 일까요?

00:15:50.010 --> 00:15:52.000
>>은 계속 진행 해야 하 고
쿼리 계획을 조정 합니다.

00:15:52.000 --> 00:15:52.860
예 쿼리 계획을 조정 합니다.

00:15:52.860 --> 00:15:54.490
다음 수정 하기 전에
업그레이드할 수 있습니다.

00:15:54.490 --> 00:15:55.350
>> 권한입니다. 자, >> 오른쪽.

00:15:55.350 --> 00:15:56.260
>> 고 있기 때문에 하는 것이 좋습니다.

00:15:56.260 --> 00:15:57.630
가 말했듯이
somethings을

00:15:58.640 --> 00:15:59.960
우물-변환 하지 않음
>> 정확 하 게.

00:15:59.960 --> 00:16:04.040
>>으로 인해 키워드 16
같은 segregator 및 일.

00:16:04.040 --> 00:16:07.150
>> 권한입니다. 확인 합니다. >> 수정,
예 더 많은 데이터에 대해 작업 하 고

00:16:07.150 --> 00:16:12.100
자세히 볼 수 있듯이
도움이 될 수 있는 데이터입니다.

00:16:12.100 --> 00:16:14.330
>>이 도구를 생길 수 있습니다.

00:16:14.330 --> 00:16:17.310
Azure SQL DB를 지원 하지 않습니다.
이 시점에서 합니까?

00:16:17.310 --> 00:16:18.650
아니면 온-프레미스만.

00:16:18.650 --> 00:16:20.650
>> 지원 하지 않습니다.
Azure SQL DB 지금 당장입니다.

00:16:20.650 --> 00:16:23.200
하지만 Vm에서 SQL 지원지 않습니다.

00:16:23.200 --> 00:16:24.750
하지만 시나리오를 수 있습니다.

00:16:24.750 --> 00:16:25.520
>> 것 같습니다.

00:16:25.520 --> 00:16:27.860
>> SQL과 SQL Vm에서 예.

00:16:27.860 --> 00:16:29.150
>> 계획이 있을?

00:16:29.150 --> 00:16:32.010
때문에 볼 생각 하는 경우
약이 봐 않을 이동 합니다.

00:16:33.380 --> 00:16:34.800
때문에 내가 ISV 또는

00:16:34.800 --> 00:16:37.150
필자는 다음과 같은
Azure SQL DB로 사랑 합니다.

00:16:37.150 --> 00:16:38.950
그러나 내 작업 부하
번역을 하 고

00:16:38.950 --> 00:16:42.290
SQL Azure에서에서 어떤 서비스 계층 아마
데이터베이스를 선택 하는 데 필요한

00:16:42.290 --> 00:16:44.290
이 같은 작업 부하 성능을?

00:16:44.290 --> 00:16:45.240
>> 예.
>> 인지 확인 하는 일종의

00:16:45.240 --> 00:16:46.620
>> 그래입니다.
것은

00:16:46.620 --> 00:16:47.280
얘기 하며

00:16:47.280 --> 00:16:47.780
>> 확인 합니다.
>> 정확 하 게.

00:16:47.780 --> 00:16:48.510
>> 난 거 하도록 지정

00:16:48.510 --> 00:16:49.170
도 지도입니다.
>> 예.

00:16:49.170 --> 00:16:50.320
>>, 날짜 또는 건입니다.

00:16:50.320 --> 00:16:52.350
>> 권한입니다. 아니오 >>
>>는 것에 우리의 사람들을

00:16:52.350 --> 00:16:53.190
우리에 대해 얘기 했습니다.

00:16:53.190 --> 00:16:54.430
>> 및
너무는 실제로 유효한 시나리오입니다.

00:16:54.430 --> 00:16:56.060
>> 정답 유용한 시나리오입니다.

00:16:56.060 --> 00:16:58.110
>> 예.
Sass, 및 암호에 대 한 밀어넣기는

00:16:58.110 --> 00:16:58.830
같이.

00:16:58.830 --> 00:16:59.330
>> 정확 하 게.

00:16:59.330 --> 00:17:00.870
>> 표시 kinda 어려울까요.

00:17:00.870 --> 00:17:01.900
>> 정확 하 게. 완전히.

00:17:01.900 --> 00:17:02.630
>> 자, 세련 된 디자인.

00:17:02.630 --> 00:17:03.960
이것은 놀라운입니다.

00:17:03.960 --> 00:17:05.630
내가 사랑 하는 관점에서 볼 때.

00:17:05.630 --> 00:17:08.970
내 첫 번째 질문은 생각 하 고
두 DMA입니다.

00:17:10.180 --> 00:17:11.370
가-
>> DA.

00:17:11.370 --> 00:17:11.910
>> DA.

00:17:11.910 --> 00:17:15.305
서 서 하지 않습니다.
정부 기관입니다.

00:17:15.305 --> 00:17:17.720
[웃음] 나타나지 않습니다.

00:17:17.720 --> 00:17:20.240
하지만 이러한 도구를 볼 수 있습니까
모여의 종류

00:17:20.240 --> 00:17:22.130
이들이 칭찬을 지키는
각각 다른 아주 잘 합니다.

00:17:22.130 --> 00:17:22.920
>> 절대적으로.

00:17:22.920 --> 00:17:23.650
>> 그래입니다.
>> 하지 않습니까?

00:17:23.650 --> 00:17:25.800
어떤 DMA 없겠지만
하지 않은,

00:17:25.800 --> 00:17:28.690
From에서 브라우저에서 볼 때
내 작업 부하 관점입니다.

00:17:28.690 --> 00:17:29.620
>>를 수정 합니다.

00:17:29.620 --> 00:17:32.840
>> 따라서 것 들
쿼리를 수정 해야 합니까?

00:17:32.840 --> 00:17:36.990
이라는 내 누른 수
이야기할 수 있는 방법이 있습니까

00:17:36.990 --> 00:17:40.880
16에 쿼리 저장을 눌러
고 그 중 일부를 활용?

00:17:40.880 --> 00:17:43.560
Kinda는 하는데
생각이 큰 소리로 왔습니다.

00:17:43.560 --> 00:17:44.440
>> 예.
확실히 생각 합니다.

00:17:44.440 --> 00:17:46.220
것 같아요
타고 다니는.

00:17:46.220 --> 00:17:47.030
>> 확인 합니다.

00:17:47.030 --> 00:17:48.980
>> 예,
우리는 토론: 겪게 되. 세련 된 디자인.

00:17:48.980 --> 00:17:50.760
>> 그 단지 다시 실행 때문입니다.

00:17:50.760 --> 00:17:51.420
>> 확인 합니다.
>> 내가 내가 생각

00:17:51.420 --> 00:17:54.710
앞서 알려 했습니다.
차 축소 지난주 라이브.

00:17:54.710 --> 00:17:55.210
>> 확인 합니다.

00:17:55.210 --> 00:17:59.510
>> 우리가 발표 기술
지난 주에 미리 봅니다.

00:17:59.510 --> 00:18:00.100
>> 확인 합니다.
>> 지금

00:18:00.100 --> 00:18:02.050
공용 보기를 사용할 수 있습니다.
하 고

00:18:02.050 --> 00:18:04.030
에서는
다운로드 센터입니다.

00:18:04.030 --> 00:18:05.850
>> 확인 합니다.
>> 지금 사람들이 보기를 들

00:18:05.850 --> 00:18:06.630
사용 합니다.

00:18:06.630 --> 00:18:08.320
어떤 의견을 보내 주십시오.

00:18:08.320 --> 00:18:08.910
모두 마찬가지입니다.
>> 지금

00:18:08.910 --> 00:18:11.410
쇼의 설명에
다운로드 링크를 배치 합니다 우리.

00:18:11.410 --> 00:18:12.710
>> 유용 합니다.
>> 절대적으로.

00:18:12.710 --> 00:18:14.825
>>를 위한 가장 좋은 방법은 무엇입니까
피드백을 제공 하 고 있습니까?

00:18:14.825 --> 00:18:17.905
>> [들리지 않음]
>>는에 있는 DA 피드백

00:18:17.905 --> 00:18:19.630
속해 있는
없는 별칭이입니다.

00:18:19.630 --> 00:18:20.530
>> 확인 합니다.

00:18:20.530 --> 00:18:24.390
>>도 되 겠는
>> 필요한 도구에서 연결 합니다.

00:18:24.390 --> 00:18:26.240
-추가
>> 자 이므로

00:18:26.240 --> 00:18:27.110
모든 해당 정보-배치
>> 및

00:18:27.110 --> 00:18:31.070
훨씬 보기 시작한 후 우리
지난 주 이후 다운로드 합니다.

00:18:31.070 --> 00:18:33.000
씨는 또한 몇 가지 의견.

00:18:33.000 --> 00:18:33.970
>> 예, 절대적으로.

00:18:33.970 --> 00:18:36.270
>> 수 있도록
주위에 대 한 재생-

00:18:36.270 --> 00:18:37.610
>> SQL 통과, 오른쪽에 당신은 도입니다.

00:18:37.610 --> 00:18:39.110
따라서 모든이 사람들이이
새로운 도구를 말하는 것!

00:18:39.110 --> 00:18:39.890
다운로드 하겠습니다.

00:18:39.890 --> 00:18:41.320
>> 예.
>> 정확 하 게.

00:18:41.320 --> 00:18:43.160
놀라운, 이것이 볼
주셔서 감사 합니다.

00:18:43.160 --> 00:18:44.050
>> 감사.

00:18:44.050 --> 00:18:48.020
>>를 드립니다 시간, 우리는
일원이 다시 kinda 약

00:18:48.020 --> 00:18:52.600
GA 있을 때 새로운 기능
빠지는 수행 하는 때문에

00:18:52.600 --> 00:18:57.790
이러한 의견 중 일부를 개선 하 고
도구 지키는 것은 이미 훌륭한

00:18:57.790 --> 00:19:01.030
에 가입
>> 종류의이 도구에 있는 새로운 소식입니다.

00:19:01.030 --> 00:19:01.908
>> 사운드 좋아입니다.
>> 세련 된 디자인.

00:19:01.908 --> 00:19:03.404
>> 안녕하세요 사람,
주셔서 감사 하 고

00:19:03.404 --> 00:19:04.372
다음에 표시 됩니다.

00:19:04.372 --> 00:19:14.372
[음악]