16 Temmuz 2015 Perşembe

15 Temmuz 2015 Çarşamba

MS SQL Server'da farklı bir cihaza TCP/IP üzerinden Bağlanmak

00:25  – by 0
Merhabalar; bu makalemde sizlere farklı bir bilgisayardan kendi SQL Server'ınıza nasıl bağlanmanız gerektiğini anlatmaya çalışacağım. Sql server üzerinde çeşitli konularda demo ve çalışma yapmak isteyen arkadaşların işine yarayacağını düşünüyorum. Öncelikle Sql server'ınız üzerinde gerekli olan konfigrasyon ayarlarınızı yapmanız gerekmektedir.

İlk olarak SQL Server Configuration dan TCP/IP 'ye çift tıklıyoruz.














Ardından karşımıza çıkan pencerede Enabled seçeneğini yes olarak değiştiriyoruz.



















Ip Adresses tab'ni tıklayıp buradan da enabled seçeneğini yes olarak değiştiriryoruz. Burada dikkatinizi çekmek istediğim bir nokta var TCP Port isimli alanın karşısında 1433 yazıyor biraz sonra size yazmanız gereken bir port numarası belirteceğim. O numara aslında buradan gelmekte. Yes seçeneğini işaretledikten sonra tamam'a basın ve karşınıza bir uyarı mesajı gelecektir. Gerekli olan değişikliklerin başarılı olabilmesi için server'ın yeniden başlatılması gerekmektedir.

Bu işlemlerden sonra sırada denetim masasında bulunan Firewall(güvenlik duvarı)ayarlarını düzenlemeye geldi. Güvenlik duvarına ulaşmak için denetim masasında bulunda arama çubuğuna güvenlik duvarı yazarak da ulaşabilirisiniz. Güvenlik duvarı menüsüne ulaştıktan sonra gelişmiş ayarları seçmeniz gerekmekte.










Açılan yeni pencereden sol üstte bulunan gelen kuralları yazısına tıklayınız.














Sağ üst köşede bulunan yeni kural yazısına tıklayınız.














Karşınıza yeni bir pencere gelecektir buradan bağlantı noktası seçeneğini seçip next'e basın.















Belirli yerel bağlantı noktaları seçeneğini seçip biraz önce bahsetmiş olduğum 1433 port numarasını yazıyoruz ve next'liyoruz.















Bundan sonraki adımlarda herhangi bir değişiklik yapmadan ileri deyip en sonra olarak bir isim vererek işlemi bitiriyoruz. Firewall kurallar listesinde gözükmesini istediğiniz herhangi bir isim verebilirsiniz.















İşlem tamamlanmıştır. En son olarak SQL Server Management Studio'ya bağlanırken Server Name isimli alana uzaktan bağlanmak istediğiniz bilgisayarın IP'sini yazarak bağlanabilirsiniz. Yalnız uzaktan bağlantılarda windows authentication güvenli olmadığı için sql server bu şekilde bağlanmanıza izin vermyecektir bundan dolayı kendi belirlemiş olduğunuz SQL Server authentication kullanıcı adı ve şifrenizle login olmanız gerekmektedir.

MİCROSOFT SQL SERVER, ERROR:18456-Login failed for user: Hatasını alan arkadaşlar muhtemelen sql server kurulumu yaparken login seçeneklerinde mixed mod seçmek yerine windows authentication seçeneğini seçtikleri için sql server'a, SQL Server authentication ile bağlanamayıp yukarıdaki hatayı almaları muhtemeldir. Bunun çözümü için Sql Server Instance'ye sağ tıklayıp properties seçeneğinden karşılarına çıkan pencereden security alanına gelip SQL SERVER and Window Authentication seçeneklerini işretledikleri taktirde problem çözülecektir.

Umarım Faydalı olur... İyi çalışmalar :)

Önemli Not: Sunucuya internetten bağlantı izni vermek ciddi güvenlik açıklarına sebebiyet verebilir. Firewall ayarlarının çok titizce yapılandırılması gerekmektedir. 

14 Temmuz 2015 Salı

Log Shipping Genel Bakış

17:55  – by 1
Bu yazımda sizlere Log Shipping'in mimarisi, çalışma prensipleri hakkında genel bilgilerden bahsetmek istiyorum. Aslında Sql server 7.0' dan itibaren sunulmuş ve high availability
seçeneklerinden en eskisi diyebiliriz. Hatta yakında Microsoft'un bu hizmeti kaldırmayı planladığı söylenmektedir. Ama benim önemsediğim bir konu çünkü özellikle yeni çıkan always on gibi yeni teknolojilerde yaşanan gelişmeleri daha iyi anlamak adına Log Shipping, Mirroring gibi daha eski high availability yöntemlerini bilmek hem bunlara nazaran çok daha karmaşık bir mimari yapıya sahip olan always on'u anlamayı kolaylaştıracak hem de hangi aşamalardan geçerek ne gibi gelişmelerin yaşandığını daha rahat anlaşılacağını düşünüyorum.

Resim1.1


Resim 1.1 görüldüğü gibi, Primary, Secondary ve Monitor Database olmak üzere elimizde toplam 3 farklı veritabanı bulunmakta.
Primary Database:
                Primary Database Log Shipping mimari içerisindeki birincil ve kullanıcıların üzerinde işlemler yaptığı veritabanımızıdır. Bu veritabanında yapılan işlemler transaction log'lara kaydedilir. Primary Database üzerinde tanımlanan job'lar vasıtasıyla belirlenen periyotlarla veritabanının log backup'ları secondary veritabanının erişme yetkisi sağlanan bir lokasyona kayıt edilir. (Bu noktada ilgili klasöre erişim yetkisi verilmelidir.) Bir diğer unutulmaması gereken detay ise transaction log backup'lar ile çalışmalar yaptığımız için ilgili veri tabanının recovery modeli Bulk logged yada full recovery olarak seçilmelidir.
Secondary Database:
                Secondary server, primary database transaction log backupların ulaştığı yerdir. Aslında gerçekleşen şey primary database'in veri düzeyinde senkronize olması sağlanmaktadır. Ama bu noktada belirtilmesi gereken bir diğer önemli nokta ise Log shipping'in senkronize(eş zamanlı) değil asenkron çalıştığı unutulmamalıdır. Secondary serverda da aynı primary database de olduğu gibi bir job tanımlanır. Belirlenen periyotlarla primary database'in log backup'ları kayıt ettiği lokasyona ulaşılıp bu backup'ları okuyarak secondary database'e restore eder.
Monitor Database:
                Monitor database log shipping yapısında olmassa olmaz bir yapı değildir. Aslında tamamen sizin çalışma stratejinize ve verilerinizin ne kadar kritik düzeyde olduğu ile alakalıdır. Genelde tavsiye edilen ise monitor server'ın kullanılmasıdır.  Monitor server primary database ve secondary server arasındaki ilişkiyi sürekli olarak izler. Primary database en son ne zaman transaction back up aldığı yada secondery server üzerinde en son ne zaman backup'ların restore edildiği izlenir. Bu noktada siz monitor database'i eğer primary database içerisinde tanımlarsanız bir fail olma durumu söz konusu olursa monitor server de devre dışı kalacağı için anlamsız bir planlama yapılmış olur bu noktada monitor database farklı bir makinede konumlandırmak fail durumlarında monitor database'in çalışmasını ve bize bildirim göndermesine engel teşkil edecek bir durumu bertaraf etmiş olacağız. Bu fiziksel mimariyi oluştururken başta dikkatli olmak gerekmektedir. Çünkü bir monitör server yapılandırıldıktan sonra log Shipping kaldırılamdan bir daha farklı bir yerde yapılandırılmasına izin verilmez başta iyi düşünülüp değerlendirildikten sonra monitor server konfigre edilmesinde fayda vardır.
Log Shipping Genel Bakış:
                İlk adım olarak log shipping modeline dahil edilecek primary database ve secondary server'lar tanımlanırlar. Yanlız şunu belirtmekte fayda var illa ki fiziksel ortamda iki farklı sunucu olmasına gerek yoktur. Aynı sunucu üzerinde farklı veritabanları arasında da log shipping özelliğini kullanabilirisiniz. Ayrıca riskleri delege etmek içinde birden fazla secondary  server da kullanılabilir. Ayrıca Log shipping işlemini yaptığımız windows kullanıcısının tüm suncularda system admin yetkilerine sahip olması gerektiğini unutmamak gerekir.  Primary ve secondary olmak üzere iki dosya paylaşmının yapılmış olması gerekmektedir. İlk olarak Primary database kaynak veritabanının transaction log'larının tutlacağı bir klasör ardından da secondary sunucu tarafından bu log'ların taşınacağı ve restore edileceği bir klasör oluşturulur. Burada dikkat edilmesi gereken bir diğer husus ise her iki sunucudaki SQL Agent'in kullandığı Windows kullanıcısının bu klasörler üzerinde yetki sahibi olması gerekmektedir.
                Log Shipping eski bir yöntem olsa bile hala kullanıldığını unutmamak gerekir. Bu sayede Log shipping bize hem disaster recovery hemde high availability çözümü sunar. Maliyet açısından da oldukça ucuz ve kullanımı ve oluşturulması kolay bir teknolojidir. Express sürümü haricinde tüm versiyonlarda kullanılabilir durumdadır. Aynı zamanda ciddi bakım gerektiren bir yapı değildir. Bir database için sınırsız sayıda log ship yapabileceğiniz yedek database imkânı sunmaktadır. StandBy mode da olan secondary database hiçbir manuel işlem yapmadan read-only modda reporting imkanındanda faydalanabilirsiniz. Ayrıca kullanıcı hataları söz konusu olduğu zaman eski transaction log backup'ları kullanarak hatadan dönülebilir.
                Tüm bunlara karşın dezavantajlarıda bulunmakta. Bunlardan bir taneside log shipping de otomatik failover imkânı bulunmamaktadır. Böle durumlarda manuel olarak failover yapılmak durumunda kalınabilir. Şimdilik log shipping hakkında söyleyecebileceklerim bunlar. Umarım faydalı olmuştur. Bir sonraki yazıda görüşmek üzere hoşçakalın...

               
               
               


8 Temmuz 2015 Çarşamba

6 Temmuz 2015 Pazartesi

Kaydol: Kayıtlar ( Atom )