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 Server エンジニアリング チームです。

00:00:15.495 --> 00:00:17.790
今日はやりたい
あなたのためのクイックデモ

00:00:17.790 --> 00:00:19.800
新しいの1つに
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
だから私は8つのプロセッサを持っている
この特定のマシンでは、

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
2 はデータベース ID です。

00:03:17.420 --> 00:03:18.665
2 つは TempDB です。

00:03:18.665 --> 00:03:23.570
1 つはファイル番号 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
ここでは、オブジェクト名
は 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
バッチが見える
1 秒あたりの要求数、

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 Server と私たちも必要です。
をクリックしてサーバーを再起動します。

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
それは1つです。それでは、先に行きましょう
をクリックし、ワークロードを再度実行します。

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