13 Ocak 2014 Pazartesi

Bir Transactional replikasyona yeniden tüm Article'lar için Snapshot oluşturmadan Article eklemek


Bu sefer sizinle kısa da olsa önemli olduğunu düşündüğüm bu konuyu paylaşmak istiyorum. Replikasyon modelleri arasında Transactional Replication en çok kullandığım ve kullanıldığını gördüğüm model. Burada Transactional Replication'ın nasıl kurulduğundan veya çalıştığından değil, ama kurulduktan sonra nasıl tüm Publication'daki Article'lar için Snapshot oluşturulmadan yeni Article (yani bir tablo gibi yeni bir nesne) eklenebileceğini anlatacağım. Bu noktada, Transactional Replication ve terimleri konusunda bilgi sahibi olduğunuzu varsayıyorum.

Transactional Replication'ı genelde arayüzden kuruyoruz. Bu kurulum sırasında New Publication Wizard'taki Snapshot Agent penceresindeki "Create a snapshot immediately and keep the snapshot available to initialize subscriptions" isimli seçeneği, kurulumu hemen tamamlamak için çoğu zaman işaretliyoruz. Fakat bu seçeneğin işaretlenmesi yüzünden, oluşturduğumuz bu Publication'a her yeni Article eklemek istediğimizde Snapshot tüm Article'lar için oluşturuluyor. Bu da hem Publication'ı oluşturduğumuz kaynak veritabanında daha çok Blocking ve işlem yükü, hem de hedef sunucudaki replike edilen veritabanında daha fazla kesinti olacağı anlamına gelir.

Eğer siz de Transactional Replication kurulumunuz esnasında  "Create a snapshot immediately and keep the snapshot available to initialize subscriptions" seçeneğini işaretlediyseniz aşağıdaki komutu replike edilen veritabanında çalıştırdığınızda aşağıdaki ekran görüntüsündeki gibi "immediate_sync" seçeneğini 0 olarak değil 1 olarak göreceksiniz.

EXEC sp_helppublication @publication = 'Publication adı'


Bu durumu engellemek ve Snapshot'ın sadece eklediğimiz yeni Article'lar için oluşturulmasını sağlamak için "immediate_sync" seçeneğine ek olarak "allow_anonymous" seçeneğini de FALSE duruma getirmemiz gerekiyor. Bunun için yine replike edilen kaynak veritabanında aşağıdaki komutları çalıştırmanız yeterlidir.

EXEC sp_changepublication
@publication = '',
@property = 'allow_anonymous', @value = 'False'

EXEC sp_changepublication
@publication = '',
@property = 'immediate_sync', @value = 'False'

Bu komutları çalıştırdıktan sonra tekrar aşağıdaki komutu çalıştırdığınızda bu sefer bu iki parametrenin değerlerini de yukarıdaki ekran görüntüsündeki gibi 0 (FALSE) olarak göreceksiniz.

EXEC sp_helppublication @publication = 'Publication adı'

Artık kaynak veritabanından yeni bir ArticlePublication'a ekleyip hedef sunucuya da replikasyon ile aktarmak için tüm Article'lar için Snapshot oluşturulması ve Reinitialization işlemi yapmanıza gerek kalmadı! Sadece eklemek istediğiniz ArticlePublication'a ister SSMS arayüzünden ister T-SQL komutuyla ekleyin ve Snapshot Agent'ı çalıştırın. Snapshot Agent'ı çalıştırdığınızda göreceğiniz gibi sadece eklediğiniz Article'lar için Script'ler oluşturulacak ve kuyrukta bekleyen replike edilecek Transaction yoksa hemen bu Script'ler hedef veritabanında da uygulanacaktır.

Not: Bazı terimleri kasti olarak size kolaylık sağlaması açısından Türkçeye çevirmedim, bu bir edebi yazı değil, teknik bir makale ve bu terimler bu uygulamayı yaparken her yerde karşınıza çıkacak olan terimlerdir.

Kolay gelsin!
Ekrem Önsoy

6 Kasım 2013 Çarşamba

SSMS 2012'de olası bir BUG?


Selam arkadaşlar,

Ortamlardan birinde Log Shipping uyguluyoruz ve T-Log yedeklerinin Restore edildiği hedef sunucudaki veritabanlarının durumlarının yanlış göründüğünü gözlemledim. Ekran görüntüsü aşağıda.


Ekran görüntüsünden de görebileceğiniz üzere, bu makinede 2 tane Log Shipping ile aktarılan veritabanı mevcut. İlki, yani "Standby / Read-Only" durumunda olan beklendiği gibi, gri veritabanı simgesi ile gösteriliyor; fakat diğerinin yanında "Restoring... / Standby / Read-Only" yazacağına sadece "Standby" yazıyor ve veritabanı simgesi de sarı renk, sanki Log Shipping ile aktarılan bir veritabanı değil gibi.

Örneğin bir işlem yapmaya kalktığımda, bekleneceği gibi aşağıdaki hatayı veriyor:


Msg 927, Level 14, State 6, Line 1
Database '' cannot be opened. It is in the middle of a restore.
Msg 8985, Level 16, State 1, Line 1
Could not locate file '' for database 'master' in sys.database_files. The file either does not exist, or was dropped. 


Böyle bir davranışı önceki versiyonlarda görmemiştim. Böyle bir şey sizin dikkatinizi çekti mi hiç?

Ekrem Önsoy

24 Ekim 2013 Perşembe

Red-Gate Deployment Manager v2.2.20.10 için izlenimlerim

Selam arkadaşlar,

RedGate, Deployment Manager ürünü için -en azından beni- oldukça tatmin eden bir dokümantasyon hazırlamış. Bu nedenle burada tek tek nasıl kurulur ve kullanılırı anlatmayacağım. Bu bilgiler için şu adrese uğrayabilirsiniz:

http://documentation.red-gate.com/display/DM2/Deployment+Manager+2+documentation

Bununla birlikte, size bu ürün nedir, niçin kullanmak istersiniz gibi bilgileri aktarmakta fayda görüyorum.

Nedir?
Şirketimizdeki üretim sunucularıyla kod geliştirme işlemleri yapılan sunucuları ayırma çalışmalarımız devam ediyor. Temel olarak yapılması istenen, yazılımcıların üretim veritabanı sunucusunda doğrudan kod geliştirme işlemi yapmaması, bunun yerine geliştirme sunucularında çalışması ve testlerden sonra değişikliklerin üretim sunucusuna Taşıma Sorumlusu tarafından taşınması. Haliyle ben de bu projenin veritabanı tarafıyla ilgileniyorum. Önceden bir özel bankada çalışırken, bu iş Beamer adı verilen bir firmanın IT ekibi tarafından yazılan uygulama ile yapılıyordu. Uygulama oldukça başarılı olduğundan dolayı, başka bankalara da satılıyordu. Fakat bizim şu anki ortamımız o kadar büyük değil, bu nedenle maliyet açısından bu uygulama bizim için doğru bir seçim olmazdı. Bize daha ziyade ya kişiselleştirilmiş bir çözüm ya da bir paket program gerekiyordu. Bu kapsamda, bu işi en uygun maliyetle ve en pratik nasıl yaparız diye düşünürken, RedGate firmasının Deployment Manager isimli ürünüyle karşılaştım.

RedGate, Deployment Manager'ın Starter Edition'ı için bir ücret talep etmiyor. Maalesef henüz Edition'ların özelliklerinin karşılaştırıldığı bir listeye ait bir dokümantasyon bulamadım. RedGate Support'a bu talebimi ilettim. Fakat şimdiye kadar benim Starter Edition'a ait gördüğüm sınırlamalar şöyle:
- En fazla 5 tane Proje (Project) oluşturulabiliyor: Her farklı veritabanı için farklı proje oluşturmak gerekiyor.
- En fazla 5 tane Ajan (Agent) kurulabiliyor: Taşıma yapılacak her hedef makineye bir ajan kurulması gerekiyor.
- Takım çalışması hakkında bazı sınırlamalar.

Niçin?
Kod değişikliklerinin önce geliştirme sunucularında yapılması ve testlerin ardından üretim sunucusuna taşınması birçok sorunu önleyecektir. Ayrıca gerek şirket içindeki teftişler olsun, şirket dışındaki diğer firmalardan gelen teftişler olsun böyle bir yapıyı size dayatacaklardır. Aksi takdirde kritik veriler çok daha fazla kişi tarafından denetimsiz olarak erişilebiliyor olacaktır.

Sonuç
Ben kendi test makinelerimde kurulumları ve testleri yaptım. Gayet iyi çalıştığını gözlemledim. Şimdi yazılımcı arkadaşlarımla da test edeceğim. Ardından eğer başka izlenimlerim olursa onları da paylaşıyor olurum.


Ekrem Önsoy


7 Ekim 2013 Pazartesi

ApexSQL Comply v2013.01.114 izlenimlerim

Selam millet!

Takip edenler az çok bilecektir, bu aralar gerek şirket için gerekse şirket dışı teftişleri için kullanmak üzere "Compliance" / "DAM (Database Activity Monitoring)" kategorisinde olan ürünler konusunda çalışıyorum.

Çok temel olarak bahsetmek gerekirse, DAM ürünlerinin birçok çeşidi var. İzlenecek sunuculara ajanlar kurularak çalışanlar, Network'ü izleyenler gibi. IBM'in Guardium'u; Imperva'nın SecureSphere'i gibi dünya çapında çok bilinen ve maliyetleri ve yetenekleri nedeniyle genelde büyük şirketler tarafından kullanılan ürünler var. Bunların yanında, Idera, ApexSQL gibi firmaların da geliştirdikleri, çok daha uygun fiyatlarla satın alabileceğiniz, sınırlı ihtiyaçlara cevap verebilecek küçük çözümler var.

Idera'nın SQL Compliance Manager ürününden ve Idera firmasından önceki yazılarımda bahsetmiştim. Bununla birlikte, geçen Cumartesi günü Microsoft Türkiye'nin İstanbul'daki merkez ofisinde gerçekleştirilen SQLSaturday (#258) etkinliğinde Idera firmasından Mehmet Taluk ve adını şu anda hatırlayamadığım başka bir Avusturyalı arkadaşla Idera ile yaşadığım sorunu tekrar ve yüzyüze konuşma fırsatı da buldum. Bu arkadaşlar gayet dost canlısı ve yardımsever olsalarda, yaşanılan sorun olduğu gibi yerinde duruyor.

Bugün, SQL Server için birçok ürün geliştiren ApexSQL firmasının geliştirdiği yeni bir ürün olan ApexSQL Comply ürününü deneme fırsatım oldu. Bu yazımda size ürün hakkındaki ilk izlenimlerimi anlatıyor olacağım. Eğer denememi devam ettirebilirsem, o zaman daha uzun süreli olan o deneyimlerimden de bahsetme fırsatı bulabilirim belki.

Ürün temel olarak 2 parçadan oluşuyor. Birinci parçası, izlenecek olan SQL Server Instance'larından toparlanacak olan verinin nerede saklanacağı ile ilgili. Adı "ApexSQL Comply central repository". Önce bunun kurulumunu yapmak gerekiyor. Daha sonra da izlenecek olan Instance'lar için "ApexSQL Comply distributed manager" uygulamasının kurulumu yapılmalı. Aksi takdirde izleme işlemine başlanamaz.




"ApexSQL Comply central repository" uygulamasını kurarken IIS6/7 ve .Net konusunda bazı eksiklerim olduğunu ve bu nedenle de Web Console'unu kuramayacağını söyledi. Ben de en azından kurabildiği kısmını görebilmek için kurulumu devam ettirdim. Bu nedenle en azından şu anda Web Console'unun neye benzediğini bilemiyorum. Fakat belli ki, raporlama vs. gibi işler için kullanılıyor.

"ApexSQL Comply" ile SELECT, DML, DDL işlemlerini hem Instance hem de veritabanı bazında izleyebiliyoruz.



Yukarıdaki ekran görüntüsünden de göreceğiniz üzere, sol tarafta veritabanlarımızın listesi var (oranın da solunda Instance'ların listesi var) ve seçtiğimiz veritabanında Tablo olsun, Stored Procedure olsun hangi nesneler için hangi işlemlerin (DDL, DML, Query/SELECT vd.) izlenebileceğini seçebiliyoruz. Bu noktada benim gördüğüm bir eksik var ki, bir tablonun alanı bazında izleme yapılamıyor. Bir tabloyu ya komple izleyebiliyor ya da hiç izleyemiyor. Bana göre bu bir eksi. Çünkü çok büyük tablolarda sadece gereken/hassas alanların izlenmesi disk ve bu veriye bağlı işlemlerin performansı açasından önemli.

Teftiş açısından en önemli şeylerden biri olan toplanan verinin değiştirilip değiştirilmediğine dair olan ispat gerekliliği ise "Verify Audit Integrity / Data integrity verification" denilen bir işlev ile sağlanıyor. Bu işlevin ne kadar verimli ve hızlı çalıştığını şu anda bilemiyorum, çünkü henüz yeterince veri birikmiş değil. Bu işlevi de test etmeyi istiyorum.




Idera Compliance Manager 4.2 (CM) ile özellik olarak karşılaştırıldığında (CM'in "before-after", sensitive columns, alarm ayarlama, olay filtreleme gibi özellikleri Comply'da yok) CM daha gelişmiş görünüyor. Bununla birlikte, ApexSQL Comply daha yeni bir ürün. Eminim zaman içerisinde yeni özellikler de eklenecektir.

Bununla birlikte, Idera CM için 3.500$ civarında bir ödeme yapmıştık. ApexSQL ise Comply için 1 senelik abonelik dahil 999$ istiyor. Abonelik, 1 sene boyunca ApexSQL personelinden destek almak ve yeni çıkan güncellemeleri yükleme hakkı veriyor. Aboneliği 3 senelik almak isterseniz de 1.499$'a geliyor.

Şimdilik ApexSQL Comply hakkındaki haberlerim bu kadar. Umarım sonra devamını da sizlerle paylaşacağım.

Ekrem Önsoy

2 Ekim 2013 Çarşamba

"Unable to create a restore plan due to break in the LSN chain"

HATA:
Unable to create a restore plan due to break in the LSN chain.


AÇIKLAMA:
SQL Server Management Studio 2012 arayüzü ile NORECOVERY modunda "Full Database Restore" işlemi yaptıktan sonra bir de "Differential Database Restore" işlemi yapmak isterseniz bu hata ile karşılaşabilirsiniz.

Sorunu araştırırken Connect'te bu konuda açılmış ve sonra da "düzeltildi" denilerek kapatılmış bir kayıt gördüm. Fakat belli ki sorun düzeltilmemiş. Çünkü benim bu sorunu yaşadığım ortamdaki SQL Server'ın versiyonu 2012 RTM + SP1 idi. Eğer SP1'den sonra CU'larla düzeltildiyse onu bilemiyorum tabii.

ÇÖZÜM:
Sorunu Restore işlemini T-SQL koduyla yaparak aşabildim.