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
>> 以符合您陳俊銘不錯。

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
>> 遷移小幫手] 類型
不要的它類似角色

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
另外還有在其第二個上
必須 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
>> 完成後，DEA
處理，並分析追蹤

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
進行這個動作的第一個步驟時我們
在生產環境中的將追蹤擷取

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 做和

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
>> 好，沒錯，
我看過的並且趨向，好了，

00:05:09.970 --> 00:05:11.687
為什麼我重新執行這個？

00:05:11.687 --> 00:05:13.990
好，如果我詢問 cuz
其他人要問。

00:05:13.990 --> 00:05:15.040
>> 絕對。
>> 我要問，

00:05:15.040 --> 00:05:17.020
我不應該呼叫
這些笨的問題。

00:05:17.020 --> 00:05:19.388
我要提出明顯的問題，
cuz [串音]。

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
>> 這是排序的類似
當您輸入 DEA，

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
>> 好了，因此
我可以啟動兩個步驟，並進入，好。

00:06:45.790 --> 00:06:46.480
>> 步驟二和幾個步驟。

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
因此，移到第二部分，
我們只是停止擷取，

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
四個的子系機器和

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
這是我們
擷取在第一個步驟。

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
你就可以一次 fo 2008 和
另一個 2016年的時間。

00:08:58.740 --> 00:09:02.021
>> 如果您記得架構
我們必須其中兩個。

00:09:02.021 --> 00:09:04.760
另一個在 A 和
另一個是 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
>>，這是我會去的地方，

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
Nick 已經顯示您的螢幕。

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
我只指清這些疑惑像我一樣
不知道其挑選數。

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
我們對 SQL 16 執行測試。

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
>> [確定]。
[串音]有兩個，

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
因此，舉例來說，it 的顯示
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
>> Cuz 種有趣的是
您知道我們幾位的原因

00:15:41.920 --> 00:15:44.430
於是他進入鮑伯防衛盾，這裡的
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 資料庫
在這個時候呢？

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 和 Vm 上的 SQL。

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 資料庫。

00:16:37.150 --> 00:16:38.950
但我的工作負載
要轉譯，和

00:16:38.950 --> 00:16:42.290
也許 Azure SQL 在何種服務層級
資料庫我需要挑選

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
這兩個指定與 cuz
每個其他非常好。

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
我不知道，這是相當
想出不見一點。

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
已告訴您更早版本，
我們去縮小 live 上星期。

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
那里的 Microsoft.com
是有別名。

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
>> 我們非常感謝您的時間中，我們
歡迎您上一步相當約

00:18:48.020 --> 00:18:52.600
GA 時沒有新功能，
是恰因為我認為是您採取

00:18:52.600 --> 00:18:57.790
某些此玩家意見並改善
工具 cuz 已經實在太酷了，

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
[音樂]