Microsoft, 2016 yılı başında SQL Server 2016 yazılımını çıkardığında Linux işletim sistemine de destek verileceğini açıklamıştı.
Yakın zamanda duyurduğu SQL Server v.Next artık Ubuntu, Red Hat Enterprise ve SUSE işletim sistemlerine kurulabiliyor.
Desteklenen sürümler:
Ubuntu 16.04 ve yukarısı.
Red Hat Enterprise Linux 7.2 ve yukarısı.
Suse Enterprise Server v12 SP2.
https://www.microsoft.com/en-us/sql-server/sql-server-vnext-including-Linux#resources
SQL Server 2016’nın Service Pack 1 güncellemesi çıktı.
https://www.microsoft.com/en-us/download/details.aspx?id=54276
Announcing SQL Server Management Studio -16.5 Release
Download SQL Server Management Studio (16.5)
New in this release
Microsoft SQL server da veri tabanımızı taşımanın birçok yöntemi vardır. Bunlar yedek alma ve yedekten geri dönme, copy database, attach/deattach, veri tabanının scriptini alıp aktarma vb. yöntemlerdir.
Veri tabanlarımız diğer bir sql sunucuya ya da aynı sql sunucudaki farklı bir disk alanına bu yöntemler ile taşınabilir.
Sistem veri tabanları ise bu yöntemler ile taşınamaz. Bunun sebebi de çalıştıkları dizin yani lokasyon bilgisi yapılandırma ayarlarının içerisinde tutulur.
Model, tempdb ve msdb veri tabanı aynı yöntem ile taşınırken master veritabanı farklı bir yöntem ile taşınmaktadır. Taşınma işlemleri kesintisiz yapılamamaktadır. Bu yüzden taşıma işlemlerini gün içerisinde yapmamalısınız.
Model, tempdb ve msdb aynı yöntem ile taşındığından sadece MSDB nin taşınması uygulamasına değineceğim. Diğer ikisi içinde aynı işlemler aynı sıra ile uygulanabilir.
Veri tabanını taşımak için öncelikle aşağıdaki sorgu ile şimdiki yerini kontrol ediyoruz.
|
1 2 3 4 5 6 7 |
-- SELECT name, physical_name AS CurrentLocation, state_desc FROM sys.master_files WHERE database_id = DB_ID(N'model'); |
Download SQL Server Management Studio (SSMS) 2016
SQL Server 2016 ile birlikte gelen yeniliklerden birisi de AlwaysOn yapısında yer alan ikincil replika sunucuları arasında için yük dengeleme özelliğidir. Bu özellik read-only modunda çalışan replika sunucuları arasında gelen isteklerin yük dağılımlı olarak yönlendirilmesini sağlar.
SQL Server 2012 ve 2014 de read-only yönlendirme trafiği yönlendirme listesindeki ilk uygun replika sunucusuna yönlendirilmekteydi. Eğer bu sunucuya erişilemez ise listedeki diğer sunucuya yönlendirilirdi. Eğer çok sayıda ikincil replika sunucunuz var ise okuma işlemlerini bu sunucular arasında yük dengeli olacak şekilde yönlendiremezsiniz.
SQL Server 2016 da sorgulamalar yük dengeli olarak sunuculara dağıtılabilmektedir.
Uygulanışı:
Yapılandırma için üç adet SQL Server 2016 sunucu kullanıyorum. Bu sunucular Windows Server 2016 üzerine kuruludur.
ORTACAG ismi ile açlışan bir AlwaysOn yapım mevcut. WINSRV01 primiary server, WINSRV02 ve 03 secondary server olarak görev yapmaktadır. Listener ismi olarak da “LST” yi kullanmaktayız.
SQL Server 2012 ve 2014 sürümlerinde iki adet senkron çalışan ikincil (secondary) replika sunucusu oluşturulabilir. Bu sunuculardan bir adeti öncelikli (primary) replika sunucusu ile otomatik failover yapabilmektedir.
SQL Server 2016 AlwaysOn teknolojisinde yapılan geliştirme sayesinde öncelikli replika sunucusu ile artık iki adet ikincil replika sunucusu otomatik failover yapabilir. Yani önceki sürümlere göre bu sayı bir artmıştır.
Görüldüğü üzere otomatik failover yapabilen sunucu sayısı artık üçtür.
Aşağıdaki sorgu ile de sunucuların yapılandırılmasını ve durumunu görebiliriz.
select replica_server_name, availability_mode_desc,failover_mode_desc, database_id, synchronization_health_desc,synchronization_state_desc,* from sys.availability_replicas as AR inner join sys.dm_hadr_database_replica_states as DRS on DRS.replica_id = AR.replica_id
Birincil sunucu çalışmayı durduğunda otomatik failover konumundaki ikincil replika sunucusu devreye girecektir. Fakat artık iki adet otomatik failover konumunda ikincil sunucu var.
Hangi sunucunun birincil sunucu olarak çalışmaya devem edeceğine Windows Failover hizmeti karar verir.
AlwaysOn rolü üzerindeki ayarlarda tercih edilen sahiplik seçeneği mevcuttur.
Bu bölümde üç adet sunucu yer alır. İlk sıradaki birincil replika sunucumuzdur. Hemen altında yer alan ikinci sıradaki sunucu ise birincil sunucumuzun başına bir şey geldiği zaman ilk olarak devreye girecek olan sunucudur. Üçüncü sırada ise son ikincil replika sunucumuz vardır. Bu sunucu son olarak devreye girer yani ikinci sıradaki sunucuda çalışmaz hale gelir ise.
Bu yapılandırılma Windows Failover Cluster menüsü üzerinden değiştirilemez. AlwaysOn replika sunucularını kaldırıp tekrar ekleyerek sıra değiştirilebilir. Fakat bu yöntemde çalışan sistem için önerilmez.
Microsoft SQL Server’ın Linked Server özelliği ile Active Directory yapınıza bağlanabilir ve group, bilgisayar, kullanıcı gibi nesnelerin bilgilerini sorgular ile çekebilirsiniz.
Linked Server olarak active directory yapınıza bağlanmak için aşağıdaki sorguyu çalıştırın.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 |
-- Ortaç Demirel -- USE [master] GO EXEC master.dbo.sp_addlinkedserver @server = N'ADSI', @srvproduct=N'Active Directory Service Interfaces', @provider=N'ADSDSOObject', @datasrc=N'adsdatasource' EXEC master.dbo.sp_addlinkedsrvlogin @rmtsrvname=N'ADSI',@useself=N'False',@locallogin=NULL,@rmtuser=N'ortacdemirel\administrator',@rmtpassword=’1234qqqQ’ GO EXEC master.dbo.sp_serveroption @server=N'ADSI', @optname=N'collation compatible', @optvalue=N'false' GO EXEC master.dbo.sp_serveroption @server=N'ADSI', @optname=N'data access', @optvalue=N'true' GO EXEC master.dbo.sp_serveroption @server=N'ADSI', @optname=N'dist', @optvalue=N'false' GO EXEC master.dbo.sp_serveroption @server=N'ADSI', @optname=N'pub', @optvalue=N'false' GO EXEC master.dbo.sp_serveroption @server=N'ADSI', @optname=N'rpc', @optvalue=N'false' GO EXEC master.dbo.sp_serveroption @server=N'ADSI', @optname=N'rpc out', @optvalue=N'false' GO EXEC master.dbo.sp_serveroption @server=N'ADSI', @optname=N'sub', @optvalue=N'false' GO EXEC master.dbo.sp_serveroption @server=N'ADSI', @optname=N'connect timeout', @optvalue=N'0' GO EXEC master.dbo.sp_serveroption @server=N'ADSI', @optname=N'collation name', @optvalue=null GO EXEC master.dbo.sp_serveroption @server=N'ADSI', @optname=N'lazy schema validation', @optvalue=N'false' GO EXEC master.dbo.sp_serveroption @server=N'ADSI', @optname=N'query timeout', @optvalue=N'0' GO EXEC master.dbo.sp_serveroption @server=N'ADSI', @optname=N'use remote collation', @optvalue=N'true' GO EXEC master.dbo.sp_serveroption @server=N'ADSI', @optname=N'remote proc transaction promotion', @optvalue=N'true' GO |
SQL Server da tabloların kilitlenmesi yani lock konumuna geçmesi durumunda tablolar üzerinde işlem yapamaz hale gelirsiniz. Birçok sebepten olabilecek lock durumu sisteminizi sıkıntıya sokabilir.
Hangi veri tabanı içerisinde kilitlenme olmuş, kilitlenen tablo hangisidir ve hangi sorgu buna sebep olmuş gibi bilgiler sorunu çözmenizde faydalı olmaktadır. Bu bilgilere Management Studio içerisinden rahatlıkla ulaşabilirsiniz.
Öncelikle sorunu tespit edip analiz edebilmek için kilitlenmiş bir tabloya ihtiyacım var. Sadece test ortamında aşağıdaki sorguyu çalıştırıp veri tabanımız altındaki bir tabloyu kilitleyebilir ve belirtilen süre içerisinde de kilitli kalmasını sağlayabiliriz.
|
1 2 3 4 5 |
-- Ortaç Demirel -- BEGIN TRAN SELECT 1 FROM Person.Person WITH (TABLOCKX) WAITFOR DELAY '00:02:00' ROLLBACK TRAN GO |
