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
>> 時間がかかる場合があります。
時々1時間以上。

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
>> だから、それらはsLogに記録されます。

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
だから、sLogからやり直し、

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がなければ、
それを行うには1分半。

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