WEBVTT

00:00:00.000 --> 00:00:10.500
[MÜZIK].

00:00:10.500 --> 00:00:12.270
Merhaba benim adım Pam,

00:00:12.270 --> 00:00:15.495
ve ben bir Program Yöneticisi ile kulüpler
SQL Server Engineering ekibi.

00:00:15.495 --> 00:00:17.790
Bugün yapmak istiyorum.
sizin için hızlı bir demo

00:00:17.790 --> 00:00:19.800
yeni biri üzerinde
SQL Server özellikleri.

00:00:19.800 --> 00:00:23.310
2019 Bellek Optimize
TempDB meta verileri.

00:00:23.310 --> 00:00:26.070
Ben zaten bir şey yaptım.
genel bakış video

00:00:26.070 --> 00:00:27.480
bu özellik nerede
Biraz konuşuyorum.

00:00:27.480 --> 00:00:29.040
ile bazı zorluklar hakkında

00:00:29.040 --> 00:00:32.295
TempDB performansı size
geçmişte karşı karşıya olabilir ve

00:00:32.295 --> 00:00:35.850
2019 yılında yaptığımız iş hakkında
TempDB performansını artırmak için.

00:00:35.850 --> 00:00:38.945
Bu yüzden izlemenizi öneririm.
video henüz görmediyseniz.

00:00:38.945 --> 00:00:41.600
Ne yapacağız?
Bu demo bugün

00:00:41.600 --> 00:00:45.185
optimize edilmiş belleğe odaklanarak
TempDB meta veri özelliği,

00:00:45.185 --> 00:00:46.805
nasıl etkinleştirdiğinizi,

00:00:46.805 --> 00:00:47.975
nasıl devre dışı kalacağını.

00:00:47.975 --> 00:00:49.640
Ama aynı zamanda, nasıl

00:00:49.640 --> 00:00:51.790
gerekip gerekmediğini söyleyin
bu özelliği açın.

00:00:51.790 --> 00:00:55.600
Sorun mu yaşıyorsun?
Bu özellik çözmek için tasarlanmıştır?

00:00:55.600 --> 00:00:58.770
O zaman atlayalım.
demo ve bir göz atın.

00:01:00.220 --> 00:01:02.960
Burada açık bir defterim var.

00:01:02.960 --> 00:01:05.420
Azure Veri Stüdyosu
birkaç komutları ile.

00:01:05.420 --> 00:01:09.050
Ne ile başlayacağız çalışıyor
SQL Server'daki iş yükü.

00:01:09.050 --> 00:01:14.315
Bellek etkinleştirmeden 2019
Optimize edilmiş TempDB meta veri özelliği

00:01:14.315 --> 00:01:15.560
ve biz bir göz atmaya çalışacağız

00:01:15.560 --> 00:01:17.930
bu çekişme
TempDB'de olabilir.

00:01:17.930 --> 00:01:21.050
Bu yüzden ilk şey ben
yapacak başlamaktır

00:01:21.050 --> 00:01:24.170
bir performans monitörü
toplama ve toplama

00:01:24.170 --> 00:01:26.120
birkaç farklı
verecek sayaçlar

00:01:26.120 --> 00:01:28.430
bize bir fikir
iş yükünün performansı.

00:01:28.430 --> 00:01:31.955
O zaman kullanacağım.
O stres aracı

00:01:31.955 --> 00:01:34.415
çok iş parçacığı çalıştırmak için.

00:01:34.415 --> 00:01:37.700
Sekiz işlemcim var.
bu özel makinede,

00:01:37.700 --> 00:01:39.950
ama 100 atıyorum.
eşzamanlı iş parçacıkları.

00:01:39.950 --> 00:01:42.350
Bu yüzden çok yoğun bir iş yüküm var.

00:01:42.350 --> 00:01:44.810
burada ve çok
ağır TempDB iş yükü.

00:01:44.810 --> 00:01:47.210
Bu basit bir saklama prosedürü.
bir geçici tablo oluşturur,

00:01:47.210 --> 00:01:48.360
içine bazı veriler koymak,

00:01:48.360 --> 00:01:49.805
ve sonra ondan seçer.

00:01:49.805 --> 00:01:52.200
Burada, Perf'te görebilirsiniz.

00:01:52.200 --> 00:01:54.090
Devam etmekte olan bazı ağırlıklarım var.

00:01:54.090 --> 00:01:55.740
sayfa mandal ağırlıkları devam ediyor.

00:01:55.740 --> 00:01:58.895
Ayrıca ortalama bekleme sürem var.

00:01:58.895 --> 00:02:00.380
burada da Perf adam listelenmiştir.

00:02:00.380 --> 00:02:02.390
Gördüğünüz gibi.
çağrılı mandal ağırlıkları

00:02:02.390 --> 00:02:04.775
ben iken oluyor
bu iş yükünü çalıştırıyor.

00:02:04.775 --> 00:02:07.640
Bu alışılmadık bir şey değil.
ağır eşzamanlı iş yükü.

00:02:07.640 --> 00:02:11.580
Burada soru ne olduğudur
bu sayfa mandal ağırlıkları?

00:02:11.580 --> 00:02:12.770
Bunu bilmiyoruz.

00:02:12.770 --> 00:02:14.405
Onlar olabilir
kullanıcı veritabanınız.

00:02:14.405 --> 00:02:16.430
TempDB'den olabilirler.

00:02:16.430 --> 00:02:18.740
Biz gerçekten sadece bilmiyoruz
performansa bakarak

00:02:18.740 --> 00:02:21.620
bu sayfanın mandal nerede monitör
ağırlıkları geliyor.

00:02:21.620 --> 00:02:23.210
Bu yüzden geri dönmek istiyorum

00:02:23.210 --> 00:02:25.850
Azure Veri Stüdyosu ve bir göz atın

00:02:25.850 --> 00:02:27.110
bize yardımcı olabilecek bir komut dosyası

00:02:27.110 --> 00:02:30.880
bu sayfanın nerede olduğunu belirleyin
mandal ağırlıkları geliyor.

00:02:30.880 --> 00:02:32.230
Görünüşe göre iş yüküm bitmiş.

00:02:32.230 --> 00:02:34.190
O yüzden tekmeleyeceğim.
geri geri böylece biz

00:02:34.190 --> 00:02:36.925
Azure Veri Stüdyosu'na bakabilirsiniz.

00:02:36.925 --> 00:02:40.090
O zaman buraya geri dönelim.

00:02:42.130 --> 00:02:47.135
Bu sorguyacağım.
ki ben odak var.

00:02:47.135 --> 00:02:51.740
Bu sorgunun yaptığı şey
tüm isteklere bakarak

00:02:51.740 --> 00:02:56.510
Sahip DM tam istek
sayfa gibi bir ağırlık türü,

00:02:56.510 --> 00:03:00.335
bir çeşit anlamı
sayfa mandal ağırlığı.

00:03:00.335 --> 00:03:04.010
Sonuçlarda görebildiklerim
burada aslında var olmasıdır

00:03:04.010 --> 00:03:07.295
olan birkaç oturum
sayfa mandalını bekliyor.

00:03:07.295 --> 00:03:09.305
Ağırlık kaynağına bakarsam,

00:03:09.305 --> 00:03:11.990
Sadece kilodan anlayabiliyorum.
içinde oldukları kaynak

00:03:11.990 --> 00:03:15.905
TempDB çünkü ağırlık
kaynak burada 2:1:1:20 olduğunu.

00:03:15.905 --> 00:03:17.420
İki veritabanı kimliği,

00:03:17.420 --> 00:03:18.665
Iki tempdb olduğunu.

00:03:18.665 --> 00:03:23.570
Bir dosya numarası 1 ve
sonra 120 sayfa numarasıdır.

00:03:23.570 --> 00:03:25.325
TempDB'de olduğunu söyleyebilirim.

00:03:25.325 --> 00:03:30.395
Ama bu yeni işlevi kullanırsam.
DMDB sayfa bilgileri olarak adlandırılan,

00:03:30.395 --> 00:03:34.039
bu bana ne yapmanızı sağlar
bu sayfa nın kaynağını almaktır

00:03:34.039 --> 00:03:38.330
ve açık çatlamak ve görmek
tam olarak ne bu sayfada.

00:03:38.330 --> 00:03:41.355
Yani bu DMDB sayfa bilgi fonksiyonu,

00:03:41.355 --> 00:03:44.150
Bu nesneyi anlıyorum.
adı ve görebilirsiniz

00:03:44.150 --> 00:03:46.810
burada nesne adı
sys şema nesneleri,

00:03:46.810 --> 00:03:48.095
hangi bir sistem tablosudur.

00:03:48.095 --> 00:03:50.944
Yani bu TempDB olduğunu
meta veri çekişmesi

00:03:50.944 --> 00:03:52.685
Bahsettiğimiz şey.

00:03:52.685 --> 00:03:54.754
Sorun da bu.

00:03:54.754 --> 00:03:58.220
bu Bellek Optimize TempDB
çözmek için meta veriler tanıtıldı.

00:03:58.220 --> 00:03:59.960
O zaman geri dönelim.
komut penceremiz.

00:03:59.960 --> 00:04:01.115
Bittiğini görebiliyoruz.

00:04:01.115 --> 00:04:02.450
Her iki sinde de idam edildi.

00:04:02.450 --> 00:04:06.005
yaklaşık 52 saniye sürdü
iş yükünü çalıştırmak için.

00:04:06.005 --> 00:04:09.675
Tabii ki sayfayı görebilirsiniz
mandal ağırlıkları oluyor.

00:04:09.675 --> 00:04:12.300
Toplu iş lerini görebiliriz.
saniyede istekler,

00:04:12.300 --> 00:04:14.100
hangi de tepesi vardır,

00:04:14.100 --> 00:04:18.225
Burada, yaklaşık 350 maksimum görelim.

00:04:18.225 --> 00:04:20.210
Yani bu olmadan
özelliği açık.

00:04:20.210 --> 00:04:22.265
O zaman devam edelim ve.
özelliği açın.

00:04:22.265 --> 00:04:23.795
Bunu yapmak için,

00:04:23.795 --> 00:04:25.925
biz özelliği etkinleştirmek gerekir

00:04:25.925 --> 00:04:29.090
SQL Server ve biz de gerekir
sunucuyu yeniden başlatmak için.

00:04:29.090 --> 00:04:34.250
Bu alter sunucu yapılandırması
komut burada yeniden başlatma gerektirir.

00:04:34.250 --> 00:04:38.875
Bu yüzden o anıyı ayarlayalacağız.
En iyi leştirilmiş TempDB meta verileri.

00:04:38.875 --> 00:04:43.540
O zaman ben devam edeceğim ve.
sunucuyu yeniden başlatın.

00:04:44.360 --> 00:04:48.025
Bunu yaptığımda,

00:04:48.025 --> 00:04:50.810
Geri dönebileceğim.

00:04:50.810 --> 00:04:54.155
Azure Veri Stüdyosu'na ve
başka bir komut çalıştırmak,

00:04:54.155 --> 00:04:57.470
sunucu özelliğini seçin
olup olmadığını görmek için komut

00:04:57.470 --> 00:05:01.160
TempDB bellek için optimize edilmiş
meta veri özelliği açıktır.

00:05:01.160 --> 00:05:03.265
O zaman bu komutu çalıştıralım.

00:05:03.265 --> 00:05:07.245
İdam edildiğini görebilirsiniz
ve özellik şimdi açıktır.

00:05:07.245 --> 00:05:10.565
Bir tane. O zaman devam edelim.
ve iş yükümüzü tekrar çalıştırın.

00:05:10.565 --> 00:05:13.470
Perf'e başlayalım.

00:05:16.490 --> 00:05:19.350
İş yükümüzden tekrar başlayalım.

00:05:19.350 --> 00:05:20.775
Aynı iş yükleri.

00:05:20.775 --> 00:05:24.130
Aynı depolanmış yordam, 100 iş parçacığı.

00:05:24.130 --> 00:05:27.080
Bir şey fark edebilirsiniz
Hemen Perf adam farklı.

00:05:27.080 --> 00:05:29.900
Her şeyden önce, toplu istekler
saniye başına çok daha yüksektir.

00:05:29.900 --> 00:05:34.520
500'ün üzerine çıkıyoruz.

00:05:34.520 --> 00:05:36.320
Hatta biraz daha yükseğe bile çıkabilir.

00:05:36.320 --> 00:05:37.580
Bunun bir süre devam edineceğini.

00:05:37.580 --> 00:05:40.790
ama aynı zamanda bu sayfayı fark
mandal ağırlıkları gitti.

00:05:40.790 --> 00:05:42.605
Artık sayfa mandal ağırlıkları yok.

00:05:42.605 --> 00:05:45.740
Azure Veri'ye geri dönersek
Studio ve ben bu komutu çalıştırın

00:05:45.740 --> 00:05:48.990
tekrar oturumları bakmak için.

00:05:48.990 --> 00:05:52.310
Oturum olmadığına dikkat edin
sayfa mandalı bekliyor.

00:05:52.310 --> 00:05:55.865
Tamamen ortadan kaldırdık.
sayfa mandal ağırlıkları.

00:05:55.865 --> 00:05:57.590
Eğer Perf'e dönersem,

00:05:57.590 --> 00:06:00.005
evet, benim iş yükü zaten bitti.

00:06:00.005 --> 00:06:02.990
Gördüğünüz gibi.
geliştirilmiş iş artışı.

00:06:02.990 --> 00:06:05.675
Ben bunları ortadan kaldırdım
sayfa mandal ağırlıkları.

00:06:05.675 --> 00:06:07.580
Eğer iş yüküme gelirsem,

00:06:07.580 --> 00:06:10.130
35 saniyede tamamlandı.

00:06:10.130 --> 00:06:13.760
karşı 52 saniye
özelliği olmadan.

00:06:13.760 --> 00:06:19.220
Yani bu özellik tasarlanmıştır
ölçeklendirmenize yardımcı olmak için

00:06:19.220 --> 00:06:23.240
ağır TempDB kadar
tartışmalı iş yükleri

00:06:23.240 --> 00:06:25.400
herhangi bir yapmadan
kod değişiklikleri hiç.

00:06:25.400 --> 00:06:28.085
Yapılandırmayı açmanız yeterlidir,

00:06:28.085 --> 00:06:31.640
sunucuyu yeniden başlatın ve
hemen geliştirilmiş olabilir

00:06:31.640 --> 00:06:33.770
ve daha az
sayfa mandal ağırlıkları

00:06:33.770 --> 00:06:36.320
TempDB tartışmalı iş yükleri üzerinde.

00:06:36.320 --> 00:06:38.300
Umarım öğrenmene yardımcı olur.

00:06:38.300 --> 00:06:40.790
hakkında biraz daha fazla
özelliği, nasıl kullanacağınız,

00:06:40.790 --> 00:06:42.860
nasıl olup olmadığını bilebilirsiniz
açmanız gerekir

00:06:42.860 --> 00:06:45.020
ya da değil ve biraz daha alır

00:06:45.020 --> 00:06:46.970
gelişmeler hakkında heyecanlı
gelen

00:06:46.970 --> 00:06:49.610
SQL Server 2019 Çok teşekkürler.

00:06:49.610 --> 00:07:04.210
[MÜZİk]

