SQL Server Archidoku (Açıklandı)

Yapılandırma/kurulum masasından notlar:

• Adlandırılmış Boru Yoluyla Bağlantı İçin. Bu seçenek varsayılan olarak devre dışıdır ve SQL Yapılandırma Yöneticisi tarafından etkinleştirilmesi gerekir.

TDS nedir?

Artık üç tür İstemci-Sunucu olduğunu biliyoruz. ArchiTecture, TDS'ye bir göz atalım:

• TDS, Tablolu Veri Akışı anlamına gelir.
• Her 3 protokol de TDS paketlerini kullanır. TDS, Ağ paketlerinde kapsüllenmiştir. Bu, istemci makineden sunucu makineye veri aktarımını sağlar.
• TDS ilk olarak Sybase tarafından geliştirildi ve şu anda sahibi olduğu Microsoft

İlişkisel Motor

İlişkisel Motor aynı zamanda Sorgu İşlemcisi olarak da bilinir. Şuna sahiptir: SQL Server Bir sorgunun tam olarak ne yapması gerektiğini ve bunun en iyi şekilde nasıl yapılabileceğini belirleyen bileşenler. Depolama motorundan veri talep ederek ve döndürülen sonuçları işleyerek kullanıcı sorgularının yürütülmesinden sorumludur.

resimde gösterildiği gibi Archiyapısal diyagram var 3 ana bileşen İlişkisel Motorun. Bileşenleri ayrıntılı olarak inceleyelim:

CMD Ayrıştırıcı

Protokol Katmanından alınan veriler daha sonra İlişkisel Motora aktarılır. “CMD Ayrıştırıcı” İlişkisel Motorun Sorgu verilerini alan ilk bileşenidir. CMD Ayrıştırıcının asıl işi sorguyu kontrol etmektir. Sözdizimsel ve Anlamsal hata. Sonunda, bir Sorgu Ağacı oluşturur. Ayrıntılı olarak tartışalım.

Söz dizimi kontrolü:

• Diğer tüm Programlama dilleri gibi MS SQL de önceden tanımlanmış Anahtar Kelimeler kümesine sahiptir. Ayrıca SQL Server'ın SQL Server'ın anladığı kendi grameri vardır.
• SELECT, INSERT, UPDATE ve daha birçokları MS SQL'in önceden tanımlanmış Anahtar Kelime listelerine aittir.
• CMD Ayrıştırıcı sözdizimsel kontrol yapar. Kullanıcıların girişi bu dil sözdizimi veya dil bilgisi kurallarına uymuyorsa, bir hata döndürür.

Örnek: Diyelim ki bir Rus bir Japon restoranına gitti. Rus dilinde fast food sipariş ediyor. Ne yazık ki garson sadece Japonca anlıyor. En bariz sonuç ne olurdu?

Cevap şu: Garson siparişi daha fazla işleyemiyor.

Gramerde veya SQL Server'ın kabul ettiği dilde herhangi bir sapma olmamalıdır. Varsa, SQL sunucusu bunu işleyemez ve dolayısıyla bir hata mesajı döndürür.

Gelecek eğitimlerde MS SQL sorgusu hakkında daha fazla bilgi edineceğiz. Yine de aşağıdaki en temel Sorgu Sözdizimini göz önünde bulundurun:

SELECT * from <TABLE_NAME>;

Şimdi, sözdiziminin ne yaptığına dair algıyı elde etmek için, kullanıcının temel sorguyu aşağıdaki gibi çalıştırıp çalıştırmadığını söyleyin:

SELECR * from <TABLE_NAME>

Kullanıcının 'SELECT' yerine “SELECR” yazdığını unutmayın.

Sonuç: CMD Ayrıştırıcısı bu ifadeyi ayrıştıracak ve hata mesajını oluşturacaktır. “SELECR” önceden tanımlanmış anahtar kelime adını ve dilbilgisini takip etmediğinden. Burada CMD Ayrıştırıcı "SELECT" ifadesini bekliyordu.

Anlamsal kontrol:

• Bu tarafından gerçekleştirilir Normalleştirici.
• En basit şekliyle Schema'da sorgulanan Sütun adı, Tablo adı olup olmadığını kontrol eder. Ve eğer varsa, onu Query'ye bağlayın. Bu aynı zamanda şu şekilde de bilinir: bağlayıcı.
• Kullanıcı sorguları VIEW içerdiğinde karmaşıklık artar. Normalizer, değiştirmeyi dahili olarak depolanan görünüm tanımıyla ve çok daha fazlasıyla gerçekleştirir.

Bunu aşağıdaki örneğin yardımıyla anlayalım –

SELECT * from USER_ID

Sonuç: CMD Ayrıştırıcısı bu ifadeyi Anlamsal kontrol için ayrıştıracaktır. Normalleştirici istenen tabloyu (USER_ID) mevcut olmadığından bulamayacağı için ayrıştırıcı bir hata mesajı verecektir.

Sorgu Ağacı Oluşturun:

• Bu adım, sorgunun çalıştırılabileceği farklı yürütme ağacı oluşturur.
• Tüm farklı ağaçların aynı istenen çıktıya sahip olduğunu unutmayın.

Doktoru

Optimize edicinin görevi kullanıcının sorgusu için bir yürütme planı oluşturmaktır. Kullanıcı sorgusunun nasıl yürütüleceğini belirleyecek plandır.

Tüm sorguların optimize edilmediğini unutmayın. SELECT, INSERT, DELETE ve UPDATE gibi DML (Veri Değiştirme Dili) komutları için optimizasyon yapılır. Bu tür sorgular önce işaretlenir ve ardından optimize ediciye gönderilir. CREATE ve ALTER gibi DDL komutları optimize edilmez ancak bunun yerine dahili bir formda derlenirler. Sorgu maliyeti CPU kullanımı, Bellek kullanımı ve Giriş/Çıkış ihtiyaçları gibi faktörlere göre hesaplanır.

Optimize edicinin rolü, en ucuz, en iyi değil, uygun maliyetli uygulama planı.

Optimizer'ın daha teknik ayrıntılarına geçmeden önce aşağıdaki gerçek hayattan örneği inceleyin:

Örnek:

Diyelim ki çevrimiçi bir Banka hesabı açmak istiyorsunuz. Hesap açmanın maksimum 2 Gün sürdüğünü zaten biliyorsunuz. Ancak aynı zamanda 20 günden az sürebilecek veya sürmeyecek 2 bankanın daha bulunduğu bir listeniz var. Hangi bankaların 2 günden az sürede işlem yaptığını belirlemek için bu bankalarla iletişime geçmeye başlayabilirsiniz. Artık 2 günden az süren bir banka bulamayabilirsiniz ve arama faaliyetinden dolayı ek zaman kaybı yaşanabilir. İlk bankada hesap açmak daha iyi olurdu.

Sonuç: Akıllıca seçmek daha önemlidir. Daha kesin olmak gerekirse, hangisini seçeceğinizi seçin seçenek en iyisidir, en ucuzu değil.

Benzer şekilde MS SQL Optimizer, dahili kapsamlı/sezgisel algoritmalar üzerinde çalışır. Amaç sorgu çalışma süresini en aza indirmektir. Optimize Edici algoritmalarının tümü mülkiyeti Microsoft ve bir sır. Rağmen, Aşağıda MS SQL Optimizer tarafından gerçekleştirilen üst düzey adımlar verilmiştir. Optimizasyon Aramaları aşağıdaki diyagramda gösterildiği gibi üç aşamayı takip eder:

Aşama 0: Önemsiz Plan Arayışı:

• Bu aynı zamanda Ön optimizasyon aşaması.
• Bazı durumlarda, yalnızca bir tane pratik, işe yarar plan olabilir, buna önemsiz plan denir. Optimize edilmiş bir plan oluşturmaya gerek yoktur. Bunun nedeni, daha fazla arama yapmanın aynı çalışma zamanı yürütme planını bulmakla sonuçlanacak olmasıdır. Üstelik, hiç gerekmeyen Optimize edilmiş Planı Aramanın ekstra maliyetiyle.
• Hiçbir Önemsiz plan bulunamazsa, o zaman 1^st Aşama başlıyor.

Aşama 1: İşlem işleme planlarını arayın

• Buna arama da dahildir Basit ve Karmaşık Plan.
• Basit Plan Arama: Sorguya dahil olan sütun ve indeksin geçmiş verileri, İstatistiksel Analiz için kullanılacaktır. Bu genellikle tablo başına bir Dizin içerir ancak bunlarla sınırlı değildir.
• Yine de basit plan bulunamazsa daha karmaşık Plan aranır. Tablo başına Çoklu Endeks içerir.

Aşama 2: Paralel İşleme ve Optimizasyon.

• Yukarıdaki stratejilerin hiçbiri işe yaramazsa Optimizer, Paralel İşleme olanaklarını arar. Bu, Makinenin işleme yeteneklerine ve yapılandırmasına bağlıdır.
• Eğer bu hala mümkün değilse son optimizasyon aşaması başlar. Artık son optimizasyon amacı, sorguyu en iyi şekilde yürütmek için diğer tüm olası seçenekleri bulmaktır. Son optimizasyon aşaması Algorithms vardır Microsoft Mülkiyet.

Sorgu Yürütücüsü

Sorgu yürütücü çağrıları Erişim yöntemi. Yürütme için gereken veri getirme mantığına yönelik bir yürütme planı sağlar. Storage Engine'den veri alındıktan sonra sonuç Protokol katmanında yayınlanır. Son olarak veriler son kullanıcıya gönderilir.

Depolama Motoru

Depolama Motorunun görevi, verileri Disk veya SAN gibi bir depolama sisteminde depolamak ve gerektiğinde verileri almaktır. Depolama motoruna derinlemesine dalmadan önce, verilerin depolama motorunda nasıl saklandığına bir göz atalım. veritabanı ve dosya türü mevcuttur.

Veri Dosyası ve Kapsamı:

Veri Dosyası, verileri fiziksel olarak veri sayfaları biçiminde saklar, her bir veri sayfası 8KB boyutundadır ve SQL Server'daki en küçük depolama birimini oluşturur. Bu veri sayfaları, kapsamları oluşturacak şekilde mantıksal olarak gruplandırılmıştır. SQL Server'da hiçbir nesneye sayfa atanmaz.

Nesnenin bakımı kapsamlar aracılığıyla yapılır. Sayfada, Sayfa Türü, Sayfa Numarası, Kullanılan Alanın Boyutu, Boş Alanın Boyutu, Sonraki Sayfa ve Önceki Sayfaya İşaretçi gibi sayfaya ilişkin meta veri bilgilerini taşıyan, 96 byte boyutunda Sayfa Başlığı adı verilen bir bölüm bulunmaktadır. , vesaire.

dosya türleri

1. Birincil dosya

• Her veritabanı bir Birincil dosya içerir.
• Bu, tablolar, görünümler, Tetikleyiciler vb. ile ilgili tüm önemli verileri depolar.
• Uzantı .mdf genellikle ancak herhangi bir uzantıda olabilir.

2. İkincil dosya

• Veritabanı birden fazla İkincil dosya içerebilir veya içermeyebilir.
• Bu isteğe bağlıdır ve kullanıcıya özel veriler içerir.
• Uzantı .nef genellikle ancak herhangi bir uzantıda olabilir.

3. Log dosyası

• Ayrıca günlükleri yaz olarak da bilinir.
• Uzantı .ldf
• İşlem Yönetimi için kullanılır.
• Bu, istenmeyen durumlardan kurtulmak için kullanılır. Taahhüt edilmemiş işlemlere geri alma gibi önemli bir görevi gerçekleştirin.

Depolama Motorunun 3 bileşeni vardır; bunlara ayrıntılı olarak bakalım.

Erişim yöntemi

Sorgu yürütücüsü ile sorgu yürütücüsü arasında bir arayüz görevi görür. Buffer Yönetici/İşlem Günlükleri.

Erişim Yönteminin kendisi herhangi bir yürütme yapmaz.

İlk eylem, sorgunun şu olup olmadığını belirlemektir:

1. Ekstreyi Seçin (DDL)
2. Seçimsiz Bildirim (DDL ve DML)

Sonuçlara göre Access Yöntemi şu adımları izler:

1. Sorgu ise DDLSELECT deyimi, sorguya iletilir Buffer müdür daha fazla işlem için.
2. Ve eğer sorgulanırsa DDL, NON-SELECT ifadesi, sorgu İşlem Yöneticisine iletilir. Bu çoğunlukla UPDATE ifadesini içerir.

Buffer müdür

Buffer yönetici aşağıdaki modüller için temel işlevleri yönetir:

• Önbelleği Planla
• Veri Ayrıştırma: Buffer önbellek ve Veri depolama
• Kirli Sayfa

Planı öğreneceğiz, Buffer ve bu bölümdeki Veri önbelleği. İşlemler bölümünde Kirli sayfaları ele alacağız.

Önbelleği Planla

• Mevcut Sorgu planı: Arabellek yöneticisi, yürütme planının depolanan Plan Önbelleğinde olup olmadığını kontrol eder. Evet ise, sorgu planı önbelleği ve ilişkili veri önbelleği kullanılır.
• İlk kez Önbellek planı: Mevcut Plan önbelleği nereden geliyor? İlk kez sorgu yürütme planı çalıştırılıyorsa ve karmaşıksa, onu Plane önbelleğinde saklamak mantıklıdır. Bu, SQL sunucusunun aynı sorguyu bir daha aldığında daha hızlı kullanılabilirlik sağlayacaktır. Yani, Plan yürütmesi ilk kez çalıştırılıyorsa, saklanan şey sorgunun kendisidir.

Veri Ayrıştırma: Buffer önbellek ve Veri Depolama

Buffer yönetici gerekli verilere erişim sağlar. Verilerin veri önbelleğinde bulunup bulunmadığına bağlı olarak aşağıdaki iki yaklaşım mümkündür:

Buffer Önbellek – Yumuşak Ayrıştırma:

Buffer Yönetici Verileri arar Buffer Veri önbelleğinde. Varsa, bu Veriler Sorgu Yürütücüsü tarafından kullanılır. Bu, Veri deposundan veri almaya kıyasla önbellekten veri alırken G/Ç işleminin sayısı azaldığından performansı artırır.

Veri Depolama - Sert Ayrıştırma:

Veriler mevcut değilse Buffer Gerekenden daha fazla yönetici Veri Depolama alanında arama yapılır. Ayrıca verileri gelecekte kullanmak üzere veri önbelleğinde saklar.

Kirli Sayfa

İşlem Yöneticisinin işleme mantığı olarak depolanır. İşlem Yöneticisi bölümünde detaylı olarak öğreneceğiz.

İşlem Yöneticisi

Erişim yöntemi Sorgunun Seçimsiz bir ifade olduğunu belirlediğinde İşlem Yöneticisi çağrılır.

Günlük Yöneticisi

• Log Manager, İşlem Günlüklerindeki günlükler aracılığıyla sistemde yapılan tüm güncellemelerin kaydını tutar.
• Günlükler var İşlem Kimliği ve Veri Değiştirme Kaydıyla Sıra Numarasını Günlüğe Kaydeder.
• Bu, takip etmek için kullanılır İşlem Gerçekleştirildi ve İşlemin Geri Alınması.

Kilit Yöneticisi

• İşlem sırasında Veri Deposundaki ilişkili veriler Kilit durumundadır. Bu işlem Kilit Yöneticisi tarafından gerçekleştirilir.
• Bu süreç şunları sağlar: veri tutarlılığı ve izolasyonu. ASİT özellikleri olarak da bilinir.

Yürütme Süreci

• Günlük Yöneticisi günlüğe kaydetmeyi başlatır ve Kilit Yöneticisi ilgili verileri kilitler.
• Verilerin kopyası şu adreste saklanır: Buffer önbelleği.
• Güncellenmesi gereken verilerin kopyası Log tamponunda tutulur ve tüm olaylar veriyi Veri tamponunda günceller.
• Verileri saklayan sayfalar aynı zamanda şu şekilde de bilinir: Kirli Sayfalar.
• Denetim Noktası ve Yazma Öncesi Günlüğü: Bu işlem, Kirli Sayfalardan Diske kadar tüm sayfaları çalıştırır ve işaretler, ancak sayfa önbellekte kalır. Frekans dakikada yaklaşık 1 çalışmadır. Ancak sayfa ilk önce günlük dosyasının Veri sayfasına gönderilir. Buffer kayıt. Bu şu şekilde bilinir: Önceden Günlüğe Yazma.
• Tembel Yazar: Kirli sayfa hafızada kalabilir. SQL sunucusu büyük bir yük gözlemlediğinde ve Buffer Yeni bir işlem için hafızaya ihtiyaç duyulursa, Kirli Sayfaları önbellekten boşaltır. Şu anda çalışıyor LRU – Son zamanlarda tampon havuzundan diske sayfa temizleme algoritması olarak kullanılıyor.

ÖZET

• Üç Tip İstemci Sunucusu Archimevcut yapılar: 1) Paylaşılan Bellek 2) TCP/IP 3) Adlandırılmış Kanallar
• Sybase tarafından geliştirilen ve artık sahip olunan TDS Microsoft, istemci makineden sunucu makineye veri aktarımı için Ağ paketleri içinde kapsüllenmiş bir pakettir.
• İlişkisel Motor üç ana bileşen içerir:CMD Ayrıştırıcı: Bu, Sözdizimsel ve Anlamsal hatalardan sorumludur ve sonunda bir Sorgu Ağacı oluşturur.Optimize Edici: Optimize edicinin rolü, en iyiyi değil, en uygun maliyetli yürütme planını bulmaktır.

  Sorgu Yürütücüsü: Sorgu yürütücüsü Erişim Yöntemini çağırır ve yürütme için gereken veri getirme mantığına yönelik yürütme planı sağlar.

• Üç tür dosya vardır: Birincil dosya, İkincil dosya ve Günlük dosyaları.
• Depolama Motoru: Aşağıdaki önemli bileşenlere sahiptirErişim yöntemi: Bu Bileşen Sorgunun Seçilmiş mi yoksa Seçilmemiş İfadesi mi olduğunu belirleyin. Çağırır Buffer ve buna göre Transfer Yöneticisi.Buffer Müdürü: Buffer yönetici Plan Önbelleği, Veri Ayrıştırma ve Kirli Sayfa için temel işlevleri yönetir.

  İşlem Yöneticisi: Günlük ve Kilit Yöneticilerinin yardımıyla Seçimsiz İşlemleri yönetir. Ayrıca, Yazma Öncesi günlük kaydının ve Tembel yazarların önemli uygulamasını kolaylaştırır.