• Öncelikle herhangi bir terslik ihtimaline karşı elimizde yeni alınmış bir veritabanı ve log yedeği olmalı
• Taşıma işlemi süresince yedek alma job’ları durdurulmalı
• Secondary Node’da veri tabanına veri hareketi durdurulur 

  
  

• Data hareketi durduğunda secondary sunucu üzerindeki veri tabanı “Not Synchronizing” durumuna düşer. Dashboard’dan görülebilir. Veri tabanını Always On’dan çıkartalım. Açılacak pencerede OK’a basalım

Veri tabanını Always On’dan çıkardıktan sonra secondary veri tabanında data file’ı yeni diske taşıyoruz. Secondary sunucuda  aşağıdaki komutu çalıştıralım:

ALTER DATABASE denemevt
MODIFY FILE (NAME = denemevt,
FILENAME = ‘C:\ndf\denemevt.mdf’);
GO

Bu komutu çalıştırdığımızda aşağıdaki uyarı ile karşılaşacağız:
The file “denemevt” has been modified in the system catalog. The new path will be used the next time the database is started.

• Secondary sunucuda sql server servisini durduralım. Daha sonra data file’ı yeni lokasyonuna taşıyalım.
• Secondary sunucuda veritabanına sağ tuşa basıp “join to availability group” diyerek veritabanını tekrar always on’a dahil edelim. Hata verirse servisi restart ettikten sonra tekrar deneyelim. Yeni diske ve dizine erişim sorunundan kaynaklanabilecek hatalar için Sql Server Servisini çalıştıran kullanıcıya data file’ın yeni klasörü için izin verelim.

• Buraya kadar tamamladıktan sonra always on’u failover yapıp bu işlemleri yeni primary sunucu için de yapmamız gerekiyor.
   

Always On Veri Tabanlarında Data File Taşımak yazısı ilk önce Yunus Emre IŞIK üzerinde ortaya çıktı.

External Protocols : İstemci ile veritabanı sunucusu arasında iletişimi sağlayan katmandır. Virtual Interface Adapter , kendine has bir donanımı olan bir protokoldür ancak 2012 versiyonundan sonra kaldırılmıştır. Shared memory hem istemci hem sunucunun aynı bilgisayar(sunucu) üzerinde bulunması durumunda bağlantı için kullanılan protokoldür.  SSMS’de host ismine mokta(.) ,localhost, 127.0.0.1 yazdığımızda gerçekleşen bağlantı shared memory protokolü ile gerçekleşir. Named pipes istemci ve sunucunun aynı LAN(Intranet) üzerinde olduğunda kullanılan bir bağlantı protokolüdür. TCP/IP de bilindiği gibi WAN ya da internet üzerinden bağlantı için kullanılan protokoldür. Varsayılan olarak 1433 numaralı port kullanılır. Bu üç protokol de iletişim için aşağıda bahsi geçecek olan TDS (tabular data stream) paketlerini kullanır.

Biz bir SQL sorgusunu istemciden sunucuya gönderdiğimizde , sorgu 4KB’lık TDS(Tabular Data Stream) paketlerine çevrilir. Bu 4KB boyut sunucu özelliklerinden değiştirilebilir. Sorguyu TDS paketine dönüştürme işlemi external protocols katmanı tarafından gerçekleştirilir.
TDS paketine dönüşmüş olan sorgu “relational engine (query processor)” isimli yapıya gelir. Bu yapı sorgunun talebinin anlaşılması, çalıştırılarak “storage engine” den verinin çekilmesi ve sonuçların işlenerek istemciye ulaştırılmasından sorumludur. Storage Engine verinin ihtiyaç olduğunda yazıldığı/okunduğu disk yapısıdır.

Burada ilk olarak “command parser” sorguyu syntax yönünden denetler. Daha sonra sorguda talep edilen tablo, view vb. gibi nesneler açısından denetler ve son olarak query tree(sorgu ağacı) oluşturur. SQL bu kontrolden geçerse, “optimizer” isimli yapıya gelir. Bu sorgu en iyi (maliyet, performans) hangi yolla çalışacaksa optimizer bizim için bir execution plan oluşturur. Plan oluştuktan sonra  “executer” isimli yapı Access methods’u çağırarak sorguyu çalıştırır. Executer sorgunun talep ettiği/ilettiği veriyi “storage engine” içerisinde “access methods” isimli yapıya iletir.

Çalışan sorgu içerisinde DDL cümleleri varsa “Access methods” “transaction manager” a yönlendirir, içerisinde sadece DML cümleleri varsa buffer manager’ a gönderir.  “Access methods” sorgunun içeriğine bakar. Sorgu yalnız select cümlesiyse buffer manager’a yönlendirir. Eğer sorgu DDL (create, alter vb.) ya da SELECT olmayan DML (insert, delete, update) ise Transaction manager’a yönlendirir.

SQLOS (SQL Operating System) : İşletim sistemiyle SQL Server’ın konuştuğu, genel anlamda I/O işlemlerinin yürütüldüğü yapıdır.

SQL Server Mimarisi yazısı ilk önce Yunus Emre IŞIK üzerinde ortaya çıktı.

Buffer Cache Hit Radio : SQL Server’ın bufffer cache den istediği ve getirdiği page miktarına dair bir orandır. Yüksek olması buffer cache’de yüksek miktarda page’e erişiliyor ve çekiliyor demektir. Page Life Expectancy değeriyle birlikte önemli bir göstergedir. Memory baskısı yoksa %90’ın üzerindedir.

Page Life Expectancy : Page’in buffer da kalma süresini gösterir. Memory baskısı yoksa yüksek değerlerdedir. Bu ve yukarıdaki değer sys.dm_os_perfomrance_counters DMV’sinden görüntülenebilir.

MEMORY_ALLOCATION_EXT  :  İşletim sisteminin ya da SQL Server’ın memory allocation süreciyle ilgili bir beklemedir.

RESOURCE_SEMAPHORE : Bir worker thread’in sorguyu çalıştırabilmek için memory kaynağına izin verilmesini bekliyor. Eş zamanlı sorgular çalıştırıldığında sıklıkla gözlenen bir beklemedir.

Working set trimmed log mesajı : SQL server error log dosyasında “A significant part of SQL Server process memory has been paged out” hatası alıyorsak, SQL Server harici bir memory baskısı altındadır.  

Hafıza Performansı yazısı ilk önce Yunus Emre IŞIK üzerinde ortaya çıktı.

Login ve User’ın Farkı yazısı ilk önce Yunus Emre IŞIK üzerinde ortaya çıktı.

Comand Prompt’ta yine sqlcmd komutuyla veritabanına bağlanabiliyorsak, “Select @@VERSION” yazarak yine versiyon görüntüleyebiliriz.

2- Error Log dosyasını notepad ile açtığınızda en üst satırda versiyon bilgisini içeren bir satır bulunur. Error Log dosyasını, kendi kurulumunuzdaki versiyon farklılığını da gözönüne alarak  şu path’den bulabilirsiniz: C:\Program Files\Microsoft SQL Server\MSSQL15.MSSQLSERVER\MSSQL\Log.
 SSMS içerisinden de bu log, Management>>SQL Server Logs altında açılabilir. Current log u seçip açtığınızda en alt satıra geldiğinizde yine versiyon bilgisini görebilirsiniz.

3 – SQL Server Management Studio’da sunucu isminde görebilirsiniz. Burada gördüğümüz rakam kurulu versiyonun numarasıdır. Bu numaralar şu versiyonları ifade etmektedir.
SQL Server 2019:15 , 2017:14, 2016:13,2014:12, 2012:11, 2008R2:8.5 , 2008:10

4 – Object Explorer’da sunucu ismine sağ tuş >> Properties penceresinde version bilgisinde yine bir üstteki maddedeki rakama ulaşılabilir.

5- Sunucu üzerindeki veritabanlarından herhangi birine sağ tuş>> properties penceresinde Options tabı içerisinde “compatibility level”  açılır kutusunda en yüksek veritabanı hangisi ise kurulu sql server versiyonu da odur.

6 – EXEC sp_server_info komutunu çalıştırdığınızda DBMS_VER kolununda versiyon bilgisine yine ulaşabilirsiniz.

SQL Server versiyonunu öğrenmek yazısı ilk önce Yunus Emre IŞIK üzerinde ortaya çıktı.

1- SQL Server Configuration Manager’ı açıyoruz.
2- Servis özellikleri penceresini açalım. Startup parametreleri tabına geçelim. Alttaki barı sağa çektiğimizde bu parametrelerden bir tanesinin master veritabanının data dosyasına, bir tanesinin de log dosyasına ait path olduğunu görürüz.

3- Bu parametreleri yeni dosya yoluna ayarlayalım.
4- SQL servisini durduralım.
5- Master veritabanının mdf ve ldf dosyasını yeni konumuna taşıyalım.
6- Servisi yeniden başlatalım.

MSDB, MODEL ve TEMPDB veritabanlarını taşımak için ise ALTER DATABASE .. MODIFY FILE komutunu kullanıyoruz. Sonrasında servisi durdurup, dosyaları yeni konumuna taşıyıp, servisi yeniden başlatıyoruz. Ancak TEMPDB veritabanı servis her başladığında baştan oluşturulduğu için, dosya taşımaya gerek yok. Yeni path girildikten sonra eski konumdan, eski dosyaları silmek yeterli.

Örnek:
ALTER DATABASE tempdb
MODIFY FILE (NAME= tempdev, FILENAME = “Z:\yeni path\tempdb.mdf’);

ALTER DATABASE tempdb
MODIFY FILE (NAME= templog, FILENAME = “Z:\yeni path\templog.ldf’);

Bu komutlar çalıştırıldıktan sonra servis restart edilmek zorundadır.

Master veritabanını taşımak yazısı ilk önce Yunus Emre IŞIK üzerinde ortaya çıktı.

Linux üzerinde de yapılandırılabiliyorKurulumunu daha sonra detaylandıracağımız Always On yapısını aşağıdaki araçlarla izleyebiliyoruz:

Always On yazısı ilk önce Yunus Emre IŞIK üzerinde ortaya çıktı.

Yapılandırılması kolaydır. Veritabanı özelliklerinde “Mirroring” tabından yapılandırılır. Sonraki yazıda yapılandırılmasının detaylarını inceleyeceğiz.

Mirroring yazısı ilk önce Yunus Emre IŞIK üzerinde ortaya çıktı.

• İkinci node herhangi bir lokasyonda olabilir. Kurulumu kolaydır. Maliyeti düşüktür
• İstenildiği takdirde mimari değiştirilip diğer HA çözümlerine geçilebilir
• Diğer sunucuya da lisans gerektirir
• İkincil sunucudan rapor alınabilir
• Veri kaybı riski vardır
• Veritabanı seviyesinde yapılır

Veritabanı özelliklerinde “Transaction Log Shipping” menüsünden yapılandırılır. Yapılandırma sonrasında Transaction Log’u önce birincil sunucuda yedeğini alan, ikincil sunucuya kopyalayan ve ikincil sunucuda da restore işlemi yapan Job’lar oluşur. Sonraki yazıda yapılandırılmasının detaylarını inceleyeceğiz.

Log Shipping yazısı ilk önce Yunus Emre IŞIK üzerinde ortaya çıktı.