WEBVTT

00:00:00.000 --> 00:00:10.560
[MÜZIK].

00:00:10.560 --> 00:00:12.975
Hey, yeni bir
Data Exposed bölümü.

00:00:12.975 --> 00:00:14.460
Benim adım Pedro Lopes.

00:00:14.460 --> 00:00:16.920
Ben bir Program Yöneticisi yim
SQL Server Engineering ekibi.

00:00:16.920 --> 00:00:18.510
Bugün, ben konuşacağım.

00:00:18.510 --> 00:00:20.670
hakkında Akıllı
Veritabanı, özellikle,

00:00:20.670 --> 00:00:23.809
Akıllı Sorgu İşleme
SQL Server 2019'da,

00:00:23.809 --> 00:00:25.925
ve ayrıca Azure SQL Veritabanı.

00:00:25.925 --> 00:00:29.390
O zaman başlayalım. Sql
Server 2019 tanıttı

00:00:29.390 --> 00:00:31.864
çığır açan sorgu
performans geliştirmeleri

00:00:31.864 --> 00:00:34.655
ve onlar Akıllı
Sorgu İşleme ailesi.

00:00:34.655 --> 00:00:37.820
Bu en son makyaj
Microsoft'un misyonu emin olmak için

00:00:37.820 --> 00:00:41.690
bu kritik paralel iş yükleri
ölçekte çalışırken geliştirmek,

00:00:41.690 --> 00:00:45.470
adaptif kalırken,
sürekli değişen veri dünyası,

00:00:45.470 --> 00:00:47.855
veriler hareket ettikçe ve
veritabanları dışında.

00:00:47.855 --> 00:00:49.670
Bu videoda, sana vereceğim.

00:00:49.670 --> 00:00:51.980
hızlı bir genel bakış
Akıllı Veritabanı dünyası

00:00:51.980 --> 00:00:53.030
bu gerçekten bir sıçrama alır

00:00:53.030 --> 00:00:56.150
önümüzdeki ile ileri
SQL Server 2019,

00:00:56.150 --> 00:00:58.700
ve bir sayı tanıtmak
dalmak olacak özellikleri

00:00:58.700 --> 00:01:02.130
diğer daha deriniçine
bu serideki videolar.

00:01:03.170 --> 00:01:07.510
Akıllı Sorgu İşleme
SQL Server'da

00:01:07.510 --> 00:01:11.245
en son veritabanında varsayılan
uyumluluk düzeyi ayarı.

00:01:11.245 --> 00:01:13.210
Bu, yükseltme den sonra,

00:01:13.210 --> 00:01:15.130
bu sadece kullanılabilir

00:01:15.130 --> 00:01:18.000
kullanmak için anahtarı çevirme
en son uyumluluk ayarı.

00:01:18.000 --> 00:01:22.030
Akıllı Sorgu İşleme
aynı zamanda geniş etki sağlar

00:01:22.030 --> 00:01:23.440
performansını artırır

00:01:23.440 --> 00:01:26.650
ile mevcut iş yükleri
en az uygulama çabası.

00:01:26.650 --> 00:01:28.390
Bu gerçekten çoğu zaman anlamına gelir,

00:01:28.390 --> 00:01:30.965
sıfır ihtiyaç vardır
kodunuzu yeniden düzenleme.

00:01:30.965 --> 00:01:33.310
Akıllı Sorgu İşleme geliştirir

00:01:33.310 --> 00:01:36.190
kritik paralel iş yükleri
ölçekte çalışırken,

00:01:36.190 --> 00:01:39.355
ve veri akar gibi ve
veritabanınızın dışında,

00:01:39.355 --> 00:01:41.380
biz buna uyum sağlayacak ve

00:01:41.380 --> 00:01:44.660
bir düzeyde korumak
öngörülebilir performans.

00:01:44.660 --> 00:01:47.450
Örneğin, tanıtarak

00:01:47.450 --> 00:01:49.880
bir geri bildirim mekanizması
bellek kullanımına,

00:01:49.880 --> 00:01:53.630
iş yükünüzün
öngörülebilir bir şekilde yürütür.

00:01:53.630 --> 00:01:58.190
Belirli bir sorgu yürütme olacak
belki çok fazla bellek almak,

00:01:58.190 --> 00:01:59.750
biz bunu düzeltebilirsiniz ve

00:01:59.750 --> 00:02:02.375
eşzamanlılığı artırmak
veritabanınızın faktörü.

00:02:02.375 --> 00:02:06.020
Eğer belirli bir özkaynak yürütme
yeterli bellek almaz ve

00:02:06.020 --> 00:02:09.560
ek IO kullanarak biter
boyunca bir dökülme olarak bilinir,

00:02:09.560 --> 00:02:11.315
o zaman biz de bulabilirsiniz

00:02:11.315 --> 00:02:13.565
ve durumu düzeltmek
böylece operasyon

00:02:13.565 --> 00:02:15.260
bellekte yürütür ve

00:02:15.260 --> 00:02:18.200
beklendiği gibi gerçekleştirir
sonraki infazlar.

00:02:18.200 --> 00:02:20.540
Bu özellik artık

00:02:20.540 --> 00:02:22.835
tüm yürütme modları
veritabanı merkezi.

00:02:22.835 --> 00:02:27.170
Daha fazla veri ambarı için toplu iş modu
ve analitik iş yükleri,

00:02:27.170 --> 00:02:31.410
ve satır modu için
kritik OLTP iş yükleri.

00:02:31.700 --> 00:02:34.640
Ayrıca yeni alanlara da giriyoruz.

00:02:34.640 --> 00:02:37.220
biz çağırıyoruz
yaklaşık sorgu işleme.

00:02:37.220 --> 00:02:40.640
Örneğin, bir senaryo düşünün
bir demiryolu şirketi tutar nerede

00:02:40.640 --> 00:02:42.350
olan bilet numaralarının parça

00:02:42.350 --> 00:02:44.935
satın alınan ve kullanılan
tüm demiryolu sistemi.

00:02:44.935 --> 00:02:47.030
Bunu takip ediyorlar.
uygulamak için

00:02:47.030 --> 00:02:49.730
bazı akış kontrol ölçümleri
ihtiyaç duyulduğunda,

00:02:49.730 --> 00:02:52.610
belki de adapte ederek
trenlerin programları,

00:02:52.610 --> 00:02:53.630
veya tren sayısı

00:02:53.630 --> 00:02:55.810
karşılamak için sistem
anın ihtiyaçları.

00:02:55.810 --> 00:02:58.920
Bu bilgiler aynı zamanda
panoda güncelleştirildi

00:02:58.920 --> 00:03:02.530
Downtown bu millet
Merkez bir göz atabilir.

00:03:02.530 --> 00:03:04.220
Şimdi, bu senaryoda bir parçası

00:03:04.220 --> 00:03:06.830
iş yükü kesinlikle olacak
bir sorgu çalıştırmak için

00:03:06.830 --> 00:03:09.020
sürekli elde bakarak

00:03:09.020 --> 00:03:12.005
tüm satır sayısı
satılan ve kullanılan biletler,

00:03:12.005 --> 00:03:14.600
ve bu muhtemelen
çok gelen

00:03:14.600 --> 00:03:17.605
büyük istikrarlı belki de
milyarlarca ve milyarlarca sıra.

00:03:17.605 --> 00:03:20.540
Şimdi, bu yinelenen sorgu
normalde alacaktı

00:03:20.540 --> 00:03:23.735
üzerinde önemli kaynaklar
sunucu, yani bellek.

00:03:23.735 --> 00:03:25.639
Eğer tekrar tekrar idam edilirse,

00:03:25.639 --> 00:03:26.690
gerçekten etkileyebilir

00:03:26.690 --> 00:03:28.900
performans özellikleri
veritabanınızın.

00:03:28.900 --> 00:03:30.670
Ancak, bu senaryoda,

00:03:30.670 --> 00:03:32.750
demiryolu şirketi
mutlaka gerekmez

00:03:32.750 --> 00:03:35.830
tüm gerçek bir sayı
satılan ve kullanılan biletler.

00:03:35.830 --> 00:03:37.790
Ama çok yüksek bir
yaklaşık yeterli

00:03:37.790 --> 00:03:40.280
tüm tetiklemek için
gerekli karar verme.

00:03:40.280 --> 00:03:42.935
Bu yaklaşık nerede
saymak farklı gelir,

00:03:42.935 --> 00:03:45.500
bir sorguya izin vererek
tekrar tekrar elde etmek için

00:03:45.500 --> 00:03:48.185
yaklaşık sayım
satılan ve kullanılan biletlerin

00:03:48.185 --> 00:03:51.080
ciddi etkileri olmadan
veritabanı performansınız

00:03:51.080 --> 00:03:55.420
normal sayım sorgunuz
bugün alırdı.

00:03:55.640 --> 00:03:58.695
Row Store'da Toplu İşlem Modunu etkinleştirerek,

00:03:58.695 --> 00:03:59.950
biz etkili bir şekilde açığa

00:03:59.950 --> 00:04:02.150
işlem modu
özellikle optimize edilmiş

00:04:02.150 --> 00:04:05.975
üzerinde analitik iş yükleri için
veritabanınızdaki herhangi bir tablo.

00:04:05.975 --> 00:04:08.180
Bu demektir ki bile
senaryolar için

00:04:08.180 --> 00:04:10.385
bir sütun deposu dizini
bir seçenek olmaz,

00:04:10.385 --> 00:04:14.395
veritabanı altyapısı hala
en iyi şekilde çalıştırın.

00:04:14.395 --> 00:04:17.375
Buna karşılık, bu kapsamı açar

00:04:17.375 --> 00:04:20.630
Adaptive join gibi özellikler
iş yükünüz tarafından kullanılacak.

00:04:20.630 --> 00:04:24.170
Yalnızca adaptif birleştirme
toplu iş modunda kullanılabilir olabilir

00:04:24.170 --> 00:04:28.940
şimdi tüm genelinde kaldıraçlı olması
tablolar ve iş yüklerinizin çoğu.

00:04:29.590 --> 00:04:33.170
Biz de bazı ele
en tekrarlayan anti-desenler

00:04:33.170 --> 00:04:36.260
için bir sorun haline
yönetilen SQL Server iş yükleri.

00:04:36.260 --> 00:04:38.150
Tablo'nun kullanımı
Değişkenler ve kullanım

00:04:38.150 --> 00:04:40.105
örneğin, Skaler UDFs

00:04:40.105 --> 00:04:42.440
ve şimdi yeni seviyeleri kilidini açabilir

00:04:42.440 --> 00:04:46.375
olan sorgu optimizasyonu
yakın zamana kadar mümkün değildir.

00:04:46.375 --> 00:04:49.310
Tüm bunlar, biz.
tartışmak daha derin ve

00:04:49.310 --> 00:04:51.080
yaklaşan videolardemolar

00:04:51.080 --> 00:04:53.270
hakkında dizi
akıllı veritabanı,

00:04:53.270 --> 00:04:56.020
özellikle akıllı
sorgu işleme.

00:04:56.020 --> 00:04:59.505
Ama bilmek istiyorsan.
bugün bu konuda daha fazla,

00:04:59.505 --> 00:05:04.200
o zaman lütfen bu aka.ms/IQP

00:05:04.200 --> 00:05:06.899
Tüm gördüğünüz URL
dokümantasyon

00:05:06.899 --> 00:05:09.535
akıllı sorgu üzerinde
SQL Veritabanlarında işleme.

00:05:09.535 --> 00:05:13.100
Bazı deneme yapmak istiyorsanız
şu anda kendiniz bunların,

00:05:13.100 --> 00:05:16.040
biz de demolar var
eğer bakabilirsiniz

00:05:16.040 --> 00:05:18.980
GitHub depomuza gidin
ve kısa URL olur

00:05:18.980 --> 00:05:22.430
aka.ms/IQPDemos olmak

00:05:22.430 --> 00:05:25.900
tüm bu bakmak mümkün
özellikleri ve kendiniz deneme.

00:05:25.900 --> 00:05:27.795
Tekrar, dikkatli ilgilen.

00:05:27.795 --> 00:05:28.980
Yakında seninle konuşacağım.

00:05:28.980 --> 00:05:43.780
[MÜZIK].

