WEBVTT

00:00:00.000 --> 00:00:01.830
>> SQL Server 2019 が提供します。

00:00:01.830 --> 00:00:04.995
と呼ばれる Linux の新機能
永続的なログ バッファ。

00:00:04.995 --> 00:00:06.960
以前は Windows で利用可能でしたが、

00:00:06.960 --> 00:00:08.385
今日でもLinux上で、

00:00:08.385 --> 00:00:10.740
そして、それはあなたが排除するのに役立ちます
可能性のあるボトルネック

00:00:10.740 --> 00:00:14.130
ログを待っているときに発生する
ディスクに 2 つのフラッシュをバッファします。

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
データファイルとログファイル
Linux での啓蒙,

00:01:05.040 --> 00:01:07.470
ハイブリッド バッファ プール
Linux と Windows,

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
これらは、通常の DIMM です。

00:01:21.730 --> 00:01:26.275
サーバーにフィードする
異なる容量で来る。

00:01:26.275 --> 00:01:30.545
の 1 つのタイプである 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
2 メガバイトを使用します
アロケーション ユニット サイズ

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
>> Linux の場合、不揮発性
デバイスコントロール

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
2 メガバイトの巨大なページ フォールトを使用し、

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
これらの場合は、2 つのサポートされています
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 は、これまで Windows のみ。

00:04:10.140 --> 00:04:12.470
SQL 2019 では、

00:04:12.470 --> 00:04:15.875
この機能は現在利用可能です
Linux だけでなく、Windowsでも。

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
1 つは許可され、その場合は許可されます。

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
>> だから何で許可されているのか
1 人につき指定する

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 Server は、
このデバイスを認識し、

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
2 つを構成しました
デバイスは NUMA ノードごとに 1 つずつです。

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 値が有効になっています
ここで true に設定され、

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