‘Genel’ Kategorisi için Arşiv

STRETCH DATABASE NEDİR? SQL SERVER 2016

Yayınlandı: 12 Ocak 2017 / Genel

SQL SERVER İLE STRETCH DATABASE KULLANIMI

Herkese Merhaba,

Bu yazımda sizlere SQL  Server 2016 ile birlikte Hybrid Cloud Solutions başlığı altında gelen yeniliklerden biri olan STRETCH DATABASE özelliğinden bahsediyor olacağım. Stretch database nedir?

Günümüz teknolojisiyle birlikte Microsoft yerinde saymayarak yeni ürünler üretmeye, varolan teknolojilerini geliştirmeye odaklanmış durumda. Bildiğimiz üzere Microsot cloud alanında da geliştirmeler yapmaya devam ederek daha güçlü durumda olmayı hedeliyor. SQL Server 2016 ile birlikte gelen yeniliklerden biri olan stretch database özelliği ile birlikte Microsoft bizlere veritabanımızdaki belli başlı verilerimizi Azure portalı üzerinde bulunan Azure SQL veritabanlarımız içerisinde tutabileceğimizi açıkladı.

Hangi tür verileri Azure’a göndermeliyiz?

Local veritabanlarımızda bulunan bir tabloyu sorguladığımızda o sorgu SQL Server’ın oluşturduğu execution plan doğrultusunda çalışarak sonuç döndürecektir. Ancak Azure’a gönderdiğimiz verileri sorguladığımızda localden çıkarak network üzerinden azure’a erişerek ve size oradaki datalara erişmenizi sağlar.

 

giris

Stretch Database yeniliğini kullanarak verilerimizi iki farklı şekilde Azure’a gönderebiliyoruz. Birinci yöntem Entire Table seçeneği. SQL Server CTP versiyonlarında Stretch DB sadece Entire Table seçeneği ile sunulmuştu. Yani siz Stretch DB özelliğini kullanmak istediğinizde tüm tabloyu azure’a göndermek zorundaydınız.

Stretch DB’nin çıkış amacı arşiv verilerimizin disklerinizde çok fazla yer tutmasını engelleyerek daha az maliyetli olan azure’a taşınmasıydı. Mesela sizin satışla ilgili bir arşiv tablonuz var. Ve siz sadece 2015 öncesi verilerinizi Azure üzerinde, 2015 ve sonraki verilerinizin ise fiziksel sunucunuzda durmasını istiyorsunuz. CTP versiyonlarındaki Stretch DB özelliği ile bunu yapamıyorduk, Ancak Microsoft SQL Server 2016 yı tam olarak sahaya sürdüğünde yukarıdaki senaryoyu karşılayabilecek bir ek geliştirme yaptı. Bu sayde tablo içindeki verilerin içeriğine göre (mesela tarih kolonları) verilerimizi bölerek azure’a gönderebiliyoruz.

 

İlk olarak stretch db için kullanacağımız bir tablo oluşturalım ve içine veri yükleyelim.

 

–create database
use master
go
Create Database StretchDB
go
use StretchDB

–create table and insert data
select * into dbo.StretchTable
from AdventureWorks2014.Sales.SalesOrderHeader

 

Bu veritabanındaki siparişler tablosuna bakıyoruz ve yıllara göre siparişlerimizi ve sipariş sayısını gruplanmış olarak görüyoruz.

–Year-based total sales
select
year(OrderDate) as Year,
count(OrderDate) as TotalSales
from StretchTable
group by year(orderdate)
order by 1

3

 

Şimdi 2014 yılında yapılan siparişlerin tarihini bugün olarak güncelleyelim.

–Update 2014’s orders as 2016’s orders
update StretchTable set OrderDate = GETDATE()
where year(OrderDate) = 2014

Verilerin son haline bakıyoruz.

4

 

Bizden istenen 2017 den önceki siparişlerimin olduğu verilerin tamamını azure’a göndermek. 2017 ve sonrasın ise local de yani diskimizde kalsın istiyoruz. İlk başta veri kavramlarından bahetmiştik. 2017 de yapılan sipairşler hot veri olarak kabul ediyoruz. 2016 ve öncesindeki verileri ise cold data olarak sınıflandırabiliriz. Bu sınıflandırma sonucunda hot data ve cold data satır sayısı aşağıdaki gibidir.

5

Stretch DB özelliğini aktif etmek için öncelikle SQL Server seviyesinde remote data archive özelliğini aktif ediyoruz.

İlk olarak  Exec sp_configure komutu ile remote data archive özelliğinin aktif olup olmadığını kontrol ediyoruz. Eğer run_value 0 ise kapalı anlamına geliyor ve aşağıdaki kod ile aktif hale getiriyoruz.

–Show remote data archive
Exec sp_configure

–Change it
EXEC sp_configure ‘remote data archive’, 1;
RECONFIGURE; GO
1

 

Stretch DB özelliğini hangi veritabanı üzerinde kullanacaksak eğer o veritabanı üzerinde stretch db özelliğini aktif hale getiriyoruz.

2

Klasik introduction ekranını geçiyoruz. 🙂

6

Bu ekranda azure’a hangi tabloları göndermek istiyorsak o tabloyu seçiyoruz. Ancak burada dikkat etmemiz gereken kısım Migrate sekmesinin altındaki Entire Table kısmı. Çünkü eğer siz tablonun tamamını azure’a taşımak istiyorsanız Entire Table seçeneğini seçmeniz gerekiyor. Eğer tablo içindeki belli veriyi taşımak istiyorsanız Entire table seçeneği ile değil, entire table yazan yere tıklayarak Choose Rows seçeneği ile devam etmemiz gerekiyor.

7

Burada azure’a göndermek istediğimiz veriler için gerekli olan koşulları belirtiyoruz. Öncelikle Choose Rows  seçeneğini seçiyoruz. Daha sonra sipariş tarihi kolonuna göre verileri sınıflandırdığımı belirtiyoruz.(OrderDate) Koşul için gerekli tarihi giriyoruz.(20160101). Daha sonra yapmış olduğumuz koşulu Check ediyoruz. SQL Server yukarıda belirtmiş olduğumuz şartlara uygun olarak gerekli kodun scriptini alta çıkarıyor.

 

8

 

Eğer Entire Table seçeneği ile devam etmiş olsaydık SQL Server bütün tablodaki tüm verileri azure’a taşıyacaktı. Daha sonra bu tabloya bir veri eklendiğinde SQL Server gidip veriyi direk Azure’daki tabloya yazacaktı. Ancak şimdi SQL Server arka planda bir Table Valued Function (TVF) oluşturacak ve gelen verinin orderdate kısmına bakarak verileri azure’a yada localdeki tabloya yazacak. Oluşturacağı TVF içerisinde yukarıda oluşturuduğu scripti kullanacak. Bu sayede gelen veriler TVF den geçerek hangi koşula uyuyorsa o koşula göre yapılarımızda tutulacak.

Şimdi Azure hesabımıza bağlanıyoruz.

9

Bu ekranda azure hesabımızla alakalı gerekli konfigurasyonları tamamlıyoruz. Azure hesabımızın bölgesini seçiyoruz. Daha sonra Azure daki Serverımızı belirliyoruz. Burada iki farklı seçenek var. Eğer siz azure hesabınızda var olan bir server üzerinde bu işlemi gerçekleştirmek istiyorsanız Existing Server seçeneğini seçerek varolan serverlardan birini seçerek devam edebilirsiniz. Eğer azure’da hiç server oluşturmadıysanız Create New Server seçeneği ile devam edebilirsiniz. Bu sayede server kurulumunu da azure portalına gitmeden defaul ayarlarıyla yapabiliyorsunuz.

10

Local ile Azure arasındaki veri alış verişi sırasına güvenlik sebebiyle oluşturulacak olan DMK için şifre giriyoruz.

11

Next diyerek süreci tamamlıyoruz.

12

 

Şimdi tüm işlemler tamamlandıktan sonra verilerimizin nerede tutulduğuna bakalım.

sp_spaceused @objname = ‘dbo.StretchTable’, @mode = N’LOCAL_ONLY’

komutuyla ilgili tablonun diskte duran satır sayısı bilgisine ulaşıyoruz. Gördüğünüz gibi 11761 adet veri diskte duruyor. Yani bizim için HOT DATA olan veriler.

13

sp_spaceused @objname = ‘dbo.StretchTable’, @mode = N’REMOTE_ONLY’ komutuylada ilgili tablonun azureda duran verinin satır sayısını kontol ediyoruz. 19704 satır veri azure’a taşınmış durumda.

 

14

 

Şimdi tablomuza bir sipariş insert edelim. Bu siparişin tarihi 20120101 olsun.

INSERT INTO [dbo].[StretchTable]
([RevisionNumber],[OrderDate],[DueDate],[ShipDate],[Status],[OnlineOrderFlag],[SalesOrderNumber],[PurchaseOrderNumber],[AccountNumber],[CustomerID],[SalesPersonID],[TerritoryID],[BillToAddressID],[ShipToAddressID],[ShipMethodID],[CreditCardID],[CreditCardApprovalCode],[CurrencyRateID],[SubTotal],[TaxAmt],[Freight],[TotalDue],[Comment],[rowguid],[ModifiedDate])
VALUES
(8,2012-01-01,GETDATE(),getdate(),5,1,’SO59814′,NULL,NULL,1,NULL,NULL,1,1,1,NULL,NULL,NULL,10,10,10,30,NULL,newid(),GETDATE())

15

Veriyi ekledikten sonra tekrar kontrol ediyoruz ve aşağıdaki gibi azure’da tutulan verimizin satır sayısı 19705 olduğunu görüyoruz. Yani eklediğimiz kayıttaki sipariş tarihi 2016 dan büyük olduğu için SQL Server tarafından stretch table oluşturduğumuzda arka planda oluşan TVF sayesinde ilgili kayıt direk azure’a eklenmiştir.

ek1

Şimdi sipariş tarihi 2017 olan bir kayıt ekleyelim.

INSERT INTO [dbo].[StretchTable]
(
[RevisionNumber],[OrderDate],[DueDate],[ShipDate],[Status],[OnlineOrderFlag],[SalesOrderNumber],[PurchaseOrderNumber]
,[AccountNumber],[CustomerID],[SalesPersonID],[TerritoryID],[BillToAddressID],[ShipToAddressID],[ShipMethodID],[CreditCardID],[CreditCardApprovalCode],[CurrencyRateID],[SubTotal],[TaxAmt],[Freight],[TotalDue],[Comment],[rowguid],[ModifiedDate]
)
VALUES
(8,getdate(),GETDATE(),getdate(),5,1,’SO59814′,NULL,NULL,1,NULL,NULL,1,1,1,NULL,NULL,NULL,10,10,10,30,NULL,newid(),GETDATE())

16

Gördüğümüz gibi sipariş tarihi 2017 olduğu için bu HOT DATA dediğimiz kısıma giriyor. TVF yönlendirmesiyle ilgili kayıt azure’a değil, direk diskimize yazılıyor. Daha önce 11761 olan diskimizdeki satır sayısı 11762 olmuştur.

ek2

SQL Server’in arka planda oluşturduğu TVF’ı fonksiyonlar altında görebiliriz.

17

Tablonun içeriğine girdiğimizde aşağıdaki gibi kod bloğunu görebiliriz.

18

Stretch Database özelliğini kapattığımızda Azure’daki verilerimize ne olacak?

Stretch DB özelliğini kapatmak istediğimizde aşağıdaki gibi iki seçenekle karşılaşıyoruz. Verileri azure’da bırak. Yada verileri tekrar azure’dan geri getir.

19

Tabloyu disable ettikten sonra veritabanının stretch db özelliğini pasife çekebiliriz. Ayrıca kurulum sırasında azure üzerinde oluşturduğunuz server’ı silmek istiyorsanız eğer azure portalına girerek ‘SQL Server’ olarak aratıp serverlera erişebilir, ilgili server’ın içine girdikten sonrada o server’ı aşağıdaki gibi kaldırabilirsiniz.

 

20

Server’ı kaldırdıktan sonra altında oluşan veritabanı kendiliğinden silinecektir.

Yenilik için kişisel yorumum : SQL Server 2016 ile birlikte gelen yenilikler SQL Server tarafını çok güçlendirdi. Stretch Database yeniliği de özellikle vizyon açısından önemli yeniliklerden biri olmakla beraber Microsoft’un bu alana yapacağı yatırımlar ve geliştirmeler ile birlikte çok  daha fazla kullanışlı hale gelecektir.

Eğer Stretch Database ile ilgileniyorsanız yada Azure üzerindeki hizmetleri kurcalamak isterseniz Microsoft bizlere denememiz için ücretsiz olarak 1 ay kullanabileceğimiz 610 TL lik deneme hesabı sunuyor. Kesinlikle değerlendirmenizi tavsiye ederim.Aşağıdaki linkten azure portalına gidip deneme hesabı açabilirsiniz.

https://azure.microsoft.com/tr-tr/free/?&wt.mc_id=AID_SEM_

Umarım sizler için faydalı olmuştur.

Bir sonraki yazıda görüşmek üzere…

 

 

 

Herkese merhaba, bu yazımın içeriğinde sırasıyla;

  • RedHat işletim sistemi kurulumu,
  • RedHat sistem konfigürasyonu,
  • RedHat işletim sistemi üzerinde ORACLE 12C veritabanı kurulumu

başlıkları altında çekmiş olduğum videoları paylaşıyor olacağım.

 

İlk olarak Oracle veritabanından bahsedecek olursak eğer, birçoğumuzun bildiği gibi sektörde en çok kullanılan veritabanları denildiğinde ilk olarak akıllara gelen Oracle ve Microsoft SQL Server veritabanlarıdır.

Microsoft SQL Server veritabanları daha çok Windows Server’lar üzerinde koşarken, Oracle veritabanları ise Linux işletim sistemleri üzerinde kullanılmaktadır. Bu süreçte daha çok Oracle Linux OS yada RedHat OS kullanılmaktadır. Ayrıca windows işletim sistemleri üzerine de kurulup kullanılabilmektedir. Ancak performans ve güvenilirlik bakımından daha çok Linux OS ‘ler tercih edilmektedir.

Yazımızın içeriğine gelecek olursak eğer daha önce çekmiş olduğum ve videoları sırasıyla burada paylaşacağım.

İlk olarak Oracle 12c veritabanımızı kuracağımız işletim sistemini kuracağız. Ben bu süreçte Redhat 6.4 versiyonunu kurarak devam ettim. Ancak siz Redhat 7.1 versiyonunun kurulumunu yaparak da işleme devam edebilirsiniz. Oracle 12C kurulumunda Redhat versiyonunun çok fazla önemi olmamaktadır.

Redhat sitesinden yada internet ortamından Redhat iso sunu indirerek bilgisayarımıza kaydediyoruz. VMware Workstation(ben vmware 10 sürümünü kullandım) üzerinde Redhat işletim sistemi kurulumu yaparken indirmiş olduğumuz bu işletim sisteminin iso dosyasını sanal makineye göstermemiz gerekecektir.

 

VMware Workstation üzerine Redhat OS kurulumuyla ilgili çekmiş olduğum video  aşağıdadır.

 

 

Redhat işletim sistemi kurulduktan sonra gerek sistemin kullanımıyla gerekse Oracle kurulumu öncesi için bazı ayarlar yapmamız gerekmektedir(Firewall gibi). Bu ayarları yaparken çekmiş olduğum video aşağıdadır.

 

 

Artık işletim sistemi kurulumu tamamlandığına göre Oracle 12C veritabanı kurulumuna geçebiliriz. Oracle veritabanı kurulumu için gerekli olan setup dosyasını http://www.oracle.com/technetwork/database/enterprise-edition/downloads/index-092322.html linkinden indirebilirsiniz. Burada 64Bit Linux işletim sistemi için gerekli dosyayı indireceksiniz.

 

Setup dosyasını indirdikten sonra kurulum için gerekli adımları yaptığım video çalışmam aşağıdadır.

 

 

Umarım sizler için faydalı olmuştur. Sonraki çalışmalarımda görüşmek üzere.

 

 

SQL SERVER’DA ERROR : 18456 SORUNU

Yayınlandı: 27 Kasım 2015 / Genel

Merhaba Arkadaşlar, bu yazımda sizlere SQL Server da sık karşılaşılan hatalardan biri olan ERROR : 18456  probleminin nedenini ve nasıl çözüleceğinden bahsedeceğim.

SQL Server’a giriş yaparken genelde WINDOWS AUTHENTICATION ile
giriş yaptığımızda problem çıkmadan giriş yapabiliyoruz. Ancak daha sonra yeni bir kullanıcı oluşturarak bu kullanıcı ile giriş yapmak istediğimizde yada var olan ‘sa’ kullanıcısı ile giriş yapmak istediğimizde LOGIN ekranında ;

Login failed for user ‘sa’.(Microsoft SQL Server, Error: 18456) gibi bir uyarı alarak giriş yapamama durumu olmaktadır.

Bu sorunun nedeni kurulum yaparken sadece WINDOWS AUTHENTICATION ile giriş yapılacağı işaretlendiği içindir. Bizim burada yapacağımız çözüm ilk olarak WINDOWS AUTHENTICATION ile giriş yapmak ve daha sonra ayarlardan SQL SERVER AUTHENTICATION
ile giriş yapılabileceğine izin vermemizdir. Son olarak ise SQL Server’ı restart ederek sorunu çözmüş oluyoruz.

Daha açıklayıcı olması açısından sorunu ve çözümü resimlerle açıklayalım.

Burada sa kullanıcısı ile giriş yaptığımızda görüldüğü gibi ERROR : 18456 hatası ile karşılaşıyoruz.

1

Aşağıdaki gibi Windows Authentication ile giriş yapıyoruz.

2

Instance üzerine sağ tıklayarak özelliklerine giriyoruz.

3

 

Properties içerisine girdikten sonra sol taraftaki menüden Security seçeneğini seçiyoruz. Daha sonra sağ taraftaki ayarlardan Server Authentication altındaki SQL Server And Windows Authentication seçeneğini seçiyoruz.

4

OK butonuna bastıktan sonra bize aşağıdaki gibi uyarı verecektir. Bu değişikliklerin geçerli olması için SQL Server ‘ı yeniden başlatmamızı istemektedir.

5

Instance üzerine sağ tıklayıp RESTART dediğimizde bizden istemiş olduğu restart işlemini gerçekleştirmiş oluyoruz.

 

6

7

Restart işlemi tamamlandıktan sonra yeniden LOGIN ekranına gelerek ‘sa’ kullanıcısı ile giriş yapıyoruz.

8

Gördüğünüz gibi ‘sa’ kullanıcısı ile LOGIN olduğumuz yazmaktadır.

9

 

Umarım sizler için faydalı olur 🙂

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

SQL SERVER DA 15405 HATASI

Yayınlandı: 27 Kasım 2015 / Genel

Herkese merhaba, bu yazımda sizlere SQL Server da karşılaştığımız 15405 hatasının nedeninden ve çözümünden bahsedeceğim.

Örneğin bir veritabanının backup dosyasını aldınız ve veritabanınıza restore ettiniz. Daha sonra ‘sa’ kullanıcısı yada başka bir kullanıcı ile bu veritabanı üzerinde değişiklikler yapmak istediniz.

Örneğin Database Diagrams sekmesine tıklayıp yeni bir diagram oluşturmak istediğinizde karşınıza ‘sa’ kullanıcısı ile bu veritabanı üzerinde yeterli yetkinizin olmadığı gibi bir uyarı alabilirsiniz. SQL Server karşınıza Aşağıdaki gibi bir hata çıkaracaktır.

“Cannot use the special principal ‘sa’. (Microsoft SQL Server, Error: 15405)”

23

Bu durumda sa kullanıcısına gerekli yetkiyi vermemiz gerekmektedir.

Kullanıcı için hangi veritabanı üzerinde yetkilendirme işlemini yapmak istiyorsak eğer o veritabanının üzerinde yeni bir sorgu açıyoruz ve

exec sp_changedbowner ‘sa’,’true’

sorgusunu çalıştırıyoruz. Burada ‘sa’ kullanıcısına ilgili veritabanı için dbowner yetkisini vermiş oluyoruz. Sorunumuz bu şekilde çözülmüş olacaktır.

Faydalı olması dileğimle… 🙂


Herkese merhaba. Bu yazımda sizlere SQL Server 2016 ile birlikte AlwaysOn High Availability yapısında bulunan replikalar için gelen yeniliklerden biri olan Round-Robin Load Balancing özelliğinden bahsedeceğim.

Microsoft, SQL Server 2016 ile birlikte Security, Performans ve Yüksek Erişilebilirlik gibi alanlarda çok önemli ve etkili yenilikler getirdi. Henüz SQL Server CTP 2.4 sürümü yayınlanmış olduğunu düşünürsek eğer, SQL Server 2016 release olana kadar geliştirmelerin devam edeceğini düşünmekteyim.

Bildiğiniz üzere SQL Server 2012 ile birlikte gelen AlwaysOn yapısıyla SQL Server da replikalar arasında yüksek erişilebilirlik sağlanmış olup, bir felaket anında production olarak çalışan sunucu fail olduğu anda otomatik failover olarak ikincil sunucu aktif hale geçip Primary mod da çalışmaya devam ederek sistemin aksamamasına neden oluyordu. Bildiğimiz gibi AlwaysOn yapısında otomatik failover node sayısı 2 iken SQL Server 2016 ile birlikte 3 olduğunu da belirtmek isterim.

Round-Robin Load Balancing yapısından bahsedecek olursak eğer, bildiğimiz gibi AlwaysOn High Availability yapısında 1 Primary + 8 Secondary olmak üzere toplam 9 Node kullanabiliyorduk. SQL Server 2016 ile birlikte gelen Round-Robin Load Balancing özelliğini kullanarak, Primary sunucumuza gelen READ işlemlerini Secondary sunucularımız üzerine sıralı bir şekilde dağıtabiliyoruz. Bu sayede Primary sunucumuzun üzerindeki read işlemlerini yönlendirerek production üzerindeki özellikle READ işlemlerinin yükünü azaltmış oluyoruz.

Round-Robin Load Balancing özelliğini kullanabilmemiz için AlwaysOn yapımızın ayakta ve sorunsuz bir şekilde çalışıyor olması gerekmektedir. Secondary sunucular üzerinde bu dağıtımı yapabilmemiz için Primary olarak çalışan SQL Server içerisindeki Master veritabanı üzerinde bir script çalıştırmamız gerekmektedir.  Bu script içerisinde,

  • Hangi Availability grup için kullanıldığını,
  • Hangi sunucuların Round-Robin Load Balancing işleminde kullanılacağını,
  • Kullanılacak sunucuların isimlerini,
  • Kullanılacak sunucuların endpoint adreslerini,
  • Tanımlanmış sunucuların Round-Robin Load Balancing işlemi sırasındaki çalışma sırasının belirtilmesi,

gibi gerekli konfigürasyonlar barınmaktadır.


Şimdi sırası ile bu işlemlerin nasıl yapıldığını ve Round-Robin Load Balancing süreci ile çalışmaya başladıktan sonraki sonuçları görüntüleyeceğiz.

1

Yukarıda gördüğünüz gibi

  • AlwaysOn yapımız çalışır durumda,
  • AG adımız SQLNEXTAG1,
  • replika isimleri SQLVNEXT-NODE1, SQLVNEXT-NODE2 ve SQLVNEXT-NODE3,
  • Senkronize çalışan veritabanımızın adı TestAlwaysOn,
  • Listenerımızın adı VNEXTLISTENER

Şimdi sırası ile her node için script içerisinde kullanacağımız INSTANCE isimleri ve ENDPOINT URL’lerini kontrol edeceğiz. İlgili ekrana gelebilmek için her replikanın üzerine gelerek Properties sekmesinden ulaşıyoruz. Şimdi aşağıda 3 node için de tek tek properties bilgilerini listeleyeceğiz.

NODE-1 İÇİN PROPERTIES

2

NODE-2 İÇİN PROPERTIES

3

NODE-3 İÇİN PROPERTIES

4

Görmüş olduğumuz gibi Round-Robin Load Balancing yapabilmemiz için script içerisinde gerekli tüm bilgilerimiz mevcut. Şimdi scriptte bu bilgileri nasıl yazdığımızı ve gerekli konfigürasyonun nasıl yapıldığına bakalım.

5

Yukarıda yazılan script görüldüğü gibi sadece primary sunucumuz içindi. Burada görüldüğü gibi AG adını, hangi replika için yazıyorsak onun adını, READ_ONLY mod için gelen connectionları kabul edileceğini ve son olarak da nereden READ yapacağı ile ilgili gerekli URL bilgisini yani endpoint bilgisini giriyoruz.

Bu işlemi kaç NODE kullanacaksak eğer kullanacağınız her node için yapmanız gerekmektedir. Bizde 3 adet node olduğu için NODE-2 ve NODE-3 içinde aynı scripti yazmam gerekiyor.

Şimdi Read Only işlemlerin yapılacağı sunucular tanımlandıktan sonra bu sunucuların hangi sırayla çalışacaklarını da yazarak SQL Server’a bildirmemiz gerekiyor. Bunu da aşağıdaki şekilde yapıyoruz.

6

Burada gördüğünüz gibi her replikanın PRIMARY olma şartında tanımlanmış sıralama senaryoları mevcuttur. İlk olarak Primary mod’da NODE-1 olma durumuna göre sıralama belirtilmiştir. Yani burada parantez içerisini okuyacak olursak eğer, READ işlemlerini için gelen connectionları sırası ile Node-2 ve Node-3 üzerine yönlendirilmesi belirtiliyor. Parantez dışındaki Node-1 kısmı ise; eğer  Node-2 veya Node-3 üzerindeki READ işlemlerinde bir sorun olursa tekrar gelip read işlemlerini Node-1 üzerinden de devam ettirebilmesi anlamına gelmektedir.

Aynı şekilde Primary’nin diğer replikalar olma durumuna göre de gerekli read senaryolarının yazıldığını görebilirsiniz.

Round-Robin Load Balancing yapabilmek için gerekli scripti yazdıktan sonra en başta belirttiğim gibi Primary olarak çalışan replikanın Master veritabanının üzerinde scripti çalıştırıyoruz.

7

Yazmış olduğumuz script çalıştıktan sonra şimdi bunu kontrol edelim. Başlat sekmesinden CMD.exe yi RUN AS ADMINISTRATOR olarak çalıştırıyoruz. Command Prompt ekranın da;

  • sqlcmd –E –S VNEXTLISTENER –d TestAlwaysOn –Q “select @@SERVERNAME” –K READONLY

komudunu yazıyoruz. Bu komut her çalıştığında serverimize READONLY mod da bir connection gönderir ve o an hangi server’ın cevap verdiğini gösterecektir.

8

Yukarıda görmüş olduğunuz gibi komutu her çalıştırdığımızda farklı node’lar cevap vermektedir. Bu da bizim en baştan beri yapmak istediğimiz Round-Robin Load Balancing özelliğinin aktif olduğunu göstermektedir.

SQL Server 2016 ile birlikte High Availability alanında gelen Round-Robin Load Balancing özelliğini aktif hale getirerek kullanmış olduk. Umarım sizler içinde faydalı bir yazı olmuştur.


İletişim için;

E-mail : gokayakbal@hotmail.com

Telefon : 0535 395 56 43

BUFFER POOL EXTENTION NEDIR?

Yayınlandı: 26 Haziran 2015 / Genel

Merhabalar, bu video da Sql Server 2014 ile birlikte gelen Buffer Pool Extention(BPE) özelliğinden bahsettim. BPE nedir,  nerede kullanılır, nasıl kullanılır gibi başlıklar altında konuyu anlatarak, videonun sonunda bir DEMO çalışması yaptım. İyi seyirler.

SQL CONSTRAINT TYPES

Yayınlandı: 1 Haziran 2015 / Genel

Merhabalar, Sql Serverda kullanılan CONSTRAINT tiplerinden bahsettiğim ve demo çalışması yapmış olduğum çalışmadır, iyi seyirler 🙂

SQL Querying Örnek Soru ve Cevapları

Yayınlandı: 6 Mayıs 2015 / Genel

Sql sorgulama ile ilgili 20 adet çalışma sorularının bulunduğu PDF dosyası. İyi çalışmalar.
İndirmek için aşağıdaki linke tıklayınız.

20-ADET SORU GÖKAY AKBAL

Subqueries In Sql

Yayınlandı: 2 Mayıs 2015 / Genel

Merhabalar, bu video da sizlere SQL de kullanılan Subqueries(İç İçe sorgular) için nasıl ve ne şartlarda kullanıldığını anlatmaya çalıştım. İyi seyirler

Parameter Sniffing

Yayınlandı: 2 Mayıs 2015 / Genel
Etiketler:,

Merhabalar, bu video da Stored Procedure kullanımında karşılaştığımız Parameter Sniffing durumundan ve çözümlerinden bahsettim. İyi seyirler.