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
manager etiketine sahip kayıtlar gösteriliyor. Tüm kayıtları göster
manager etiketine sahip kayıtlar gösteriliyor. Tüm kayıtları göster
24 Ekim 2013 Perşembe
20 Eylül 2013 Cuma
Idera SQL Compliance Manager - Deneyim 4
Selamlar!
Bu uygulama ve Idera firması beni ziyadesiyle yordu, siz de yorulmayın diye SQL Compliance Manager ile ilgili yaşadığım tecrübeleri aktarmaya devam ediyorum.
Bir önceki yazımda sizlere SQL Compliance Manager uygulamasının Integrity Check özelliğinden kısaca bahsetmiştim. Bu uygulamayı alırken, bu özelliği özellikle dikkate aldım. Çünkü önceden bankalar için ve/veya bankalarla ve teftişleriyle çalışmıştım. Bir gün birilerinin "iyi, güzel, siz kritik işlemleri kayıt altına alıyorsunuz; fakat bu kayıt altına alınan verileri birilerinin değiştirmediğini nasıl garanti ediyorsunuz?" sorusunu soracağından adım gibi emindim. Zira, gün geldi ve bu soru soruldu. Tabii ki hemen Integrity Check işlevinden faydalanmak istedim ve çalıştırdım. Ne oldu dersiniz? Günler geçti ve işlem sonunda zaman aşımına uğradı. Tekrar ve tekrar sorun devam etti.
Tabii ki Case açtım hemen, Haziran ayında. İlkten bir şey üretemedi Support ekibi. Zaman aşımı ve Blocking kaynaklı olası bir sorunu düşünerek SQL Server tarafında bazı ayarlamalar yaptım. Bu olası sorunları da eledikten sonra Idera Support ne istediyse yardımcı oldum kendilerine. 3 ay süren ve daha geçen gün sonuçlanan bu Case nedeniyle öncelikle Idera'yı bol bol kutladım. Kendilerine "sevgi dolu" postalar gönderdim. Sonunda bana ne dediler dersiniz? Integrity Check özelliğinin kullanımı için 20GB'lık bir veritabanı öneriyoruz dediler. Yani bunun üstündeki bir veritabanında Integrity Check işlevinin çalışırlığına garanti veremiyorlar. Biz ise sadece 2 tabloyu SELECT ve DML işlemleri için Audit ediyoruz; diğer takip edilen şeyler ise DLL ve güvenlik ile ilgili; ki firmamız bir banka falan da değil. Sırf bu şekilde aylık 370GB'lık veri birikiyor! 20GB nerede, 370GB nerede. Hem de bu 370GB, sadece BİR ayda biriken veri. Diğerleri zaten arşivleniyor. Yani bırakın arşivlenen veriyi, 1 aylık veri için bile Integrity Check işlevi kullanılamıyor. Gelin de durumu çalıştığınız kurumların teftişlerine açıklayın?
Bu tür uygulamalar için Integrity Check işlevi olmazsa olmazdır. Eğer bu özellik olmazsa, biriktirdiğiniz verinin hiçbir anlamı yoktur. Ben de bu uygulamayı bu özellik nedeniyle tavsiye etmiştim bizim yönetime. Ve tahmin edin! Ne Idera'nın Web sitesinde ne de hiçbir dokümantasyonda "20GB" gibi "tavsiye edilen" bir kısıtlamadan bahsedilmiyor! 3 ay süren bir Case'den sonra ancak bu sonuca ulaşabiliyorsunuz!
Tabii ki bu noktada biz artık farklı bir arayışa geçeceğiz. Belki sonraki bir yazımda da bundan bahsederim.
Ekrem Önsoy - DBA
Bu uygulama ve Idera firması beni ziyadesiyle yordu, siz de yorulmayın diye SQL Compliance Manager ile ilgili yaşadığım tecrübeleri aktarmaya devam ediyorum.
Bir önceki yazımda sizlere SQL Compliance Manager uygulamasının Integrity Check özelliğinden kısaca bahsetmiştim. Bu uygulamayı alırken, bu özelliği özellikle dikkate aldım. Çünkü önceden bankalar için ve/veya bankalarla ve teftişleriyle çalışmıştım. Bir gün birilerinin "iyi, güzel, siz kritik işlemleri kayıt altına alıyorsunuz; fakat bu kayıt altına alınan verileri birilerinin değiştirmediğini nasıl garanti ediyorsunuz?" sorusunu soracağından adım gibi emindim. Zira, gün geldi ve bu soru soruldu. Tabii ki hemen Integrity Check işlevinden faydalanmak istedim ve çalıştırdım. Ne oldu dersiniz? Günler geçti ve işlem sonunda zaman aşımına uğradı. Tekrar ve tekrar sorun devam etti.
Tabii ki Case açtım hemen, Haziran ayında. İlkten bir şey üretemedi Support ekibi. Zaman aşımı ve Blocking kaynaklı olası bir sorunu düşünerek SQL Server tarafında bazı ayarlamalar yaptım. Bu olası sorunları da eledikten sonra Idera Support ne istediyse yardımcı oldum kendilerine. 3 ay süren ve daha geçen gün sonuçlanan bu Case nedeniyle öncelikle Idera'yı bol bol kutladım. Kendilerine "sevgi dolu" postalar gönderdim. Sonunda bana ne dediler dersiniz? Integrity Check özelliğinin kullanımı için 20GB'lık bir veritabanı öneriyoruz dediler. Yani bunun üstündeki bir veritabanında Integrity Check işlevinin çalışırlığına garanti veremiyorlar. Biz ise sadece 2 tabloyu SELECT ve DML işlemleri için Audit ediyoruz; diğer takip edilen şeyler ise DLL ve güvenlik ile ilgili; ki firmamız bir banka falan da değil. Sırf bu şekilde aylık 370GB'lık veri birikiyor! 20GB nerede, 370GB nerede. Hem de bu 370GB, sadece BİR ayda biriken veri. Diğerleri zaten arşivleniyor. Yani bırakın arşivlenen veriyi, 1 aylık veri için bile Integrity Check işlevi kullanılamıyor. Gelin de durumu çalıştığınız kurumların teftişlerine açıklayın?
Bu tür uygulamalar için Integrity Check işlevi olmazsa olmazdır. Eğer bu özellik olmazsa, biriktirdiğiniz verinin hiçbir anlamı yoktur. Ben de bu uygulamayı bu özellik nedeniyle tavsiye etmiştim bizim yönetime. Ve tahmin edin! Ne Idera'nın Web sitesinde ne de hiçbir dokümantasyonda "20GB" gibi "tavsiye edilen" bir kısıtlamadan bahsedilmiyor! 3 ay süren bir Case'den sonra ancak bu sonuca ulaşabiliyorsunuz!
Tabii ki bu noktada biz artık farklı bir arayışa geçeceğiz. Belki sonraki bir yazımda da bundan bahsederim.
Ekrem Önsoy - DBA
5 Ağustos 2013 Pazartesi
Idera SQL Compliance Manager - Deneyim 3
Selam!
Bu ürün ile bunca deneyimden sonra rahatça söyleyebilirim ki, bu ürün "yeterince meşgul" sistemler için kesinlikle uygun bir ürün değil!
"Yeterince meşgul"ü nasıl tanımlayacağım konusunda emin değilim, fakat şöyle bir veri paylaşabilirim; eğer SQL Compliance Manager ile takip ettiğiniz işlek tablonuzu hem DML hem de SELECT işlemleri için takip ediyorsanız, veritabanında bulunan diğer tabloları da DML işlemleri için takip ediyorsanız ve biriken aylık veri 220GB boyutunda ise; o zaman hem arşivleme konusunda, hem de Integrity Check gibi konularda büyük sıkıntılar yaşayabilirsiniz.
Arşivleme ile kastettiğim, örneğin bir aydan daha yaşlı olan biriken verileri arşivlemek isteyip, arşivlenen veritabanını da sıkıştırıp başka bir yere taşıyıp arşiv veritabanını silip yerden kazanmak isteyebilirsiniz.
Integrity Check ise, örneğin bir banka sizden SQL Compliance Manager ile toparlanan verinin değiştirilip değiştirilmediğinin garantisini isterse çalıştırıp verinin değişmediğini kanıtlayabileceğiniz bir işlevdir.
SQL Compliance Manager ile izleyip 200 - 250GB boyutunda biriken aylık bir veriniz varsa, o zaman arşivleme ve Integrity Check ile başınızın belaya girmesi işten bile değildir. Idera Support ile bu konuları çok konuştum. Maalesef bir sonuç elde edemiyorum.
Bunun yanında şunu da belirtmekte fayda var, SQL Compliance Manager'ın hedef sistemde çalışan Collection Service'inin RAM sınırlama ayarı yok. Bu nedenle örneğin sunucuda 32GB RAM varsa ve SQL Compliance Manager'ın işleyeceği çok veri birikmişse, o zaman SQL Compliance Manager 13GB'tan fazla RAM kullanmak isteyebiliyor. Bu da özellikle hedef sunucuda bir SQL Server Instance'ınız varsa, RAM savaşlarına neden olabiliyor. Idera Support'a sorduğumda, bu ürünün bir RAM üst sınır ayarlaması olmadığını belirttiler.
Özetle, bence SQL Compliance Manager, izlediğiniz veritabanındaki tablolardan toplanan veriler 50GB'ı aşmıyorsa uygun bir ürün olabilir. Aksi takdirde, ürünün bu halini kesinlikle önermiyorum.
Not: Benim kullandığım versiyon SQL Compliance Manager 4.3'dür.
Bu ürün ile bunca deneyimden sonra rahatça söyleyebilirim ki, bu ürün "yeterince meşgul" sistemler için kesinlikle uygun bir ürün değil!
"Yeterince meşgul"ü nasıl tanımlayacağım konusunda emin değilim, fakat şöyle bir veri paylaşabilirim; eğer SQL Compliance Manager ile takip ettiğiniz işlek tablonuzu hem DML hem de SELECT işlemleri için takip ediyorsanız, veritabanında bulunan diğer tabloları da DML işlemleri için takip ediyorsanız ve biriken aylık veri 220GB boyutunda ise; o zaman hem arşivleme konusunda, hem de Integrity Check gibi konularda büyük sıkıntılar yaşayabilirsiniz.
Arşivleme ile kastettiğim, örneğin bir aydan daha yaşlı olan biriken verileri arşivlemek isteyip, arşivlenen veritabanını da sıkıştırıp başka bir yere taşıyıp arşiv veritabanını silip yerden kazanmak isteyebilirsiniz.
Integrity Check ise, örneğin bir banka sizden SQL Compliance Manager ile toparlanan verinin değiştirilip değiştirilmediğinin garantisini isterse çalıştırıp verinin değişmediğini kanıtlayabileceğiniz bir işlevdir.
SQL Compliance Manager ile izleyip 200 - 250GB boyutunda biriken aylık bir veriniz varsa, o zaman arşivleme ve Integrity Check ile başınızın belaya girmesi işten bile değildir. Idera Support ile bu konuları çok konuştum. Maalesef bir sonuç elde edemiyorum.
Bunun yanında şunu da belirtmekte fayda var, SQL Compliance Manager'ın hedef sistemde çalışan Collection Service'inin RAM sınırlama ayarı yok. Bu nedenle örneğin sunucuda 32GB RAM varsa ve SQL Compliance Manager'ın işleyeceği çok veri birikmişse, o zaman SQL Compliance Manager 13GB'tan fazla RAM kullanmak isteyebiliyor. Bu da özellikle hedef sunucuda bir SQL Server Instance'ınız varsa, RAM savaşlarına neden olabiliyor. Idera Support'a sorduğumda, bu ürünün bir RAM üst sınır ayarlaması olmadığını belirttiler.
Özetle, bence SQL Compliance Manager, izlediğiniz veritabanındaki tablolardan toplanan veriler 50GB'ı aşmıyorsa uygun bir ürün olabilir. Aksi takdirde, ürünün bu halini kesinlikle önermiyorum.
Not: Benim kullandığım versiyon SQL Compliance Manager 4.3'dür.
9 Haziran 2013 Pazar
Idera SQL Compliance Manager - Deneyim 2
Selam!
Bu konudaki deneyimlerimi ürünü kullandıkça paylaşacağımı önceden de belirtmiştim, bu nedenle 2 aylık kullanımdan sonra bu konuda bir güncelleme yapmak istedim.
Özellikle uygulamanın arşivleme özelliği hakkında çok çektiğimi belirtmem şart! Biriken veri çok olunca, varsayılan SQLConnectionTimeout süresi kesinlikle yeterli gelmiyor ve arşivleme aşamasında arşivleme işi sürekli zaman aşımına uğruyor ve arşivleme kesintiye uğruyordu. Bu sorun için Case açtım ve sorun üstünde çalışmaya başladık. Sorunun başından beri kendilerine sorunun SQLConnectionTimeout Property'sinin değerinden kaynaklandığını düşündüğümü iletmeme rağmen, malum ilk erişim noktalarındaki insanlar genelde teknik bilgiye sahip olmadığından gereksiz yere uzadı sorunun çözümü. O arada, elle arşivleme işlemlerine devam etmek durumunda kaldım, çünkü veriler çığ gibi büyüyordu. Neyse ki 2 ayın sonunda SQLConnectionTimeout değerini nereden değiştirebileceğimi söylediler ve 3600 saniyeyi 2 saate çıkarıp sorunumu çözdüm.
Olur da yarın öbür gün sizin de başınıza gelirse, aşağıdaki yolu izleyerek sorununuzu çözebilirsiniz:
a) Regedit'i açın ve şuraya gidin: HKLM\Software\Idera\SQLcomplia
b) Adı SqlCommandTimeout olan bir DWORD değeri yaratın
c) Buraya kaydedilen SQL komutu zaman aşımı süresi saniye ölçüsündedir. Varsayılan değer de 300 saniyedir. Örneğin bu süreyi 3600 saniyeye (1 saat) çıkarabilirsiniz.
d) Bu değişiklikten sonra, değişikliğin devreye girmesi için Collection Service'in yeniden başlatması gerekiyor.
Hadi hayırlı uğurlu olsun =)
Ekrem Önsoy
Bu konudaki deneyimlerimi ürünü kullandıkça paylaşacağımı önceden de belirtmiştim, bu nedenle 2 aylık kullanımdan sonra bu konuda bir güncelleme yapmak istedim.
Özellikle uygulamanın arşivleme özelliği hakkında çok çektiğimi belirtmem şart! Biriken veri çok olunca, varsayılan SQLConnectionTimeout süresi kesinlikle yeterli gelmiyor ve arşivleme aşamasında arşivleme işi sürekli zaman aşımına uğruyor ve arşivleme kesintiye uğruyordu. Bu sorun için Case açtım ve sorun üstünde çalışmaya başladık. Sorunun başından beri kendilerine sorunun SQLConnectionTimeout Property'sinin değerinden kaynaklandığını düşündüğümü iletmeme rağmen, malum ilk erişim noktalarındaki insanlar genelde teknik bilgiye sahip olmadığından gereksiz yere uzadı sorunun çözümü. O arada, elle arşivleme işlemlerine devam etmek durumunda kaldım, çünkü veriler çığ gibi büyüyordu. Neyse ki 2 ayın sonunda SQLConnectionTimeout değerini nereden değiştirebileceğimi söylediler ve 3600 saniyeyi 2 saate çıkarıp sorunumu çözdüm.
Olur da yarın öbür gün sizin de başınıza gelirse, aşağıdaki yolu izleyerek sorununuzu çözebilirsiniz:
a) Regedit'i açın ve şuraya gidin: HKLM\Software\Idera\SQLcomplia
b) Adı SqlCommandTimeout olan bir DWORD değeri yaratın
c) Buraya kaydedilen SQL komutu zaman aşımı süresi saniye ölçüsündedir. Varsayılan değer de 300 saniyedir. Örneğin bu süreyi 3600 saniyeye (1 saat) çıkarabilirsiniz.
d) Bu değişiklikten sonra, değişikliğin devreye girmesi için Collection Service'in yeniden başlatması gerekiyor.
Hadi hayırlı uğurlu olsun =)
Ekrem Önsoy
4 Nisan 2013 Perşembe
Idera SQL Compliance Manager - Deneyim 1
Merhaba,
Geçen ay sizlere bu üründen biraz bahsetmiştim. Tekrar çok kısa özetlemek gerekirse ürünün özellikle küçük ve orta ölçekli, SQL Server Standard Edition kullanan ve Veritabanı seviyesinde teftiş (Auditing) yapmak isteyen firmalarda kullanılabileceğini belirtmiştim.
Bir aydır ürünü Production ortamında test ettim. Çeşitli sorunlarla karşılaştım. Tabii bu sayede ürünün nasıl çalıştığı ile ilgili de daha fazla bilgi edinebildim.
Ürün temel olarak, kaynaktaki veritabanından kendi Agent'ı ile aldığı bilgileri (Trace veya doğrudan T-Log dosyasından) sıkıştırarak Collection Service'inin çalıştığı hedef sunucuya gönderiyor ve burada önce sıkıştırılan dosyaları açıyor ve ardından da depo olarak kullandığı veritabanına kaydediyor. Benim sorun yaşadığım kısım işte tam da bu işleme sırasında Parser'ın Parse sorunlarıyla karşılaşmasıyla çıktı. Tabii bu sorun da başka sorunları doğurmuş, sorunun üstünde çalışınca karşılaştığım tüm sorunların bundan kaynaklandığını anladık. Destek Amerika'dan verildiği için aramızda 7 saat fark var, bu nedenle Windows Live Meeting'leri buna göre düzenleyerek, destek mühendisi arkadaşın da yardımıyla sorunu tespit ettik ve hâlâ üstünde çalışmaya devam ediyoruz.
Efendim yolumuza devam etmek için şimdilik bu sorunu geçersek, -çünkü öyle veya böyle uygulama çalışıyor, fakat bazı şeyleri bu Bug yüzünden kaçırıyor diye düşünüyorum- uygulama SQL Server 2000'i dahi destekliyor. Sunucu, veritabanı, kullanıcı, nesne ve alan bazında denetim yapabiliyorsunuz. Biriken veriler veritabanında biriktiği için ve veritabanı da Enterprise Edition olmadığı için haliyle sıkıştırılarak saklanmıyor ve bu da veritabanının gün geçtikçe büyümesine neden oluyor. Herkesin ortamı ve ihtiyaçları farklı elbette, fakat sadece ve sadece fikir vermesi açısından şöyle bir örnek verebilirim, çalıştığım ortamda sadece bir veritabanındaki bir tabloda gerçekleşen DML işlemlerini ve sadece birkaç alan için de SELECT (Selective Columns) işlemlerini denetliyorum ve sadece 2 günde depo olarak SQL Compliance Manager tarafından kullanılan veritabanının boyutu 16,5GB oldu.
SQL Compliance Manager'ın kendi arşivleme sistemi de var. Bunu da en azından ayda bir kere çalıştırılacak şekilde ayarlamam gerekecek ve oluşan veritabanını da sıkıştırarak (sıkıştırarak yedeğini alıp sonra da arşivlenen veritabanını silerek) saklamam gerekecek diye düşünüyorum. Henüz bunu test etmedim, bu da ayrı bir yazının konusu olur.
Şimdilik bu kadar.
Ekrem Önsoy
Geçen ay sizlere bu üründen biraz bahsetmiştim. Tekrar çok kısa özetlemek gerekirse ürünün özellikle küçük ve orta ölçekli, SQL Server Standard Edition kullanan ve Veritabanı seviyesinde teftiş (Auditing) yapmak isteyen firmalarda kullanılabileceğini belirtmiştim.
Bir aydır ürünü Production ortamında test ettim. Çeşitli sorunlarla karşılaştım. Tabii bu sayede ürünün nasıl çalıştığı ile ilgili de daha fazla bilgi edinebildim.
Ürün temel olarak, kaynaktaki veritabanından kendi Agent'ı ile aldığı bilgileri (Trace veya doğrudan T-Log dosyasından) sıkıştırarak Collection Service'inin çalıştığı hedef sunucuya gönderiyor ve burada önce sıkıştırılan dosyaları açıyor ve ardından da depo olarak kullandığı veritabanına kaydediyor. Benim sorun yaşadığım kısım işte tam da bu işleme sırasında Parser'ın Parse sorunlarıyla karşılaşmasıyla çıktı. Tabii bu sorun da başka sorunları doğurmuş, sorunun üstünde çalışınca karşılaştığım tüm sorunların bundan kaynaklandığını anladık. Destek Amerika'dan verildiği için aramızda 7 saat fark var, bu nedenle Windows Live Meeting'leri buna göre düzenleyerek, destek mühendisi arkadaşın da yardımıyla sorunu tespit ettik ve hâlâ üstünde çalışmaya devam ediyoruz.
Efendim yolumuza devam etmek için şimdilik bu sorunu geçersek, -çünkü öyle veya böyle uygulama çalışıyor, fakat bazı şeyleri bu Bug yüzünden kaçırıyor diye düşünüyorum- uygulama SQL Server 2000'i dahi destekliyor. Sunucu, veritabanı, kullanıcı, nesne ve alan bazında denetim yapabiliyorsunuz. Biriken veriler veritabanında biriktiği için ve veritabanı da Enterprise Edition olmadığı için haliyle sıkıştırılarak saklanmıyor ve bu da veritabanının gün geçtikçe büyümesine neden oluyor. Herkesin ortamı ve ihtiyaçları farklı elbette, fakat sadece ve sadece fikir vermesi açısından şöyle bir örnek verebilirim, çalıştığım ortamda sadece bir veritabanındaki bir tabloda gerçekleşen DML işlemlerini ve sadece birkaç alan için de SELECT (Selective Columns) işlemlerini denetliyorum ve sadece 2 günde depo olarak SQL Compliance Manager tarafından kullanılan veritabanının boyutu 16,5GB oldu.
SQL Compliance Manager'ın kendi arşivleme sistemi de var. Bunu da en azından ayda bir kere çalıştırılacak şekilde ayarlamam gerekecek ve oluşan veritabanını da sıkıştırarak (sıkıştırarak yedeğini alıp sonra da arşivlenen veritabanını silerek) saklamam gerekecek diye düşünüyorum. Henüz bunu test etmedim, bu da ayrı bir yazının konusu olur.
Şimdilik bu kadar.
Ekrem Önsoy
5 Mart 2013 Salı
Idera SQL Compliance Manager
Selam arkadaşlar,
Çalıştığım ortamlardan birinde, veritabanlarından bazıları, bazı bankalarla çalıştığımız ve bu çalışmaların sonucunda üretilen kritik verileri barındırıyor. Bu nedenle çeşitli bankaların yaptıkları teftişlerde, kritik verilerin kimler tarafından değiştirildiği, bu verilere kimler tarafından ulaşıldığı, bu trafiğin kayıtlarının tutulup tutulmadığı ve raporlanıp raporlanamayacağı gibi sorular sorulup, taleplerde bulunuluyor.
Bahsini ettiğim ortamda kullanılan SQL Server, Standard Edition olduğundan dolayı, yukarıda bahsini ettiğim teftişlerin talep ettiği gereksinimleri Enterprise Edition'ın Database Audit özelliği ile karşılayamıyoruz. Çünkü bildiğiniz gibi Database Audit özelliği SQL Server'ın sadece Enterprise Edition'ında (ve SQL Server 2008 R2 Datacenter Edition) mevcut.
Bu gereksinim ve ortam nedeniyle ben de araştırmaya koyuldum. Birçok uygulama ile karşılaştım, SQL Server (>=2008) Enterprise Edition'ın Database Audit özelliğini taklit edebilen sadece bir uygulama bulabildim. Bu da, yazının başlığını da oluşturan, Idera firmasına ait olan SQL Compliance Manager isimli uygulama.
SQL Compliance Manager, DML işlemlerinin yanı sıra, kendini diğer benzeri ürünlerden SELECT işlemlerini de kayıt altına alarak ayırıyor. Çok ayrıntılı bir şekilde Auditing yapmak mümkün. Tablo ve Alan bazında Audit işlemi yapılabiliyor. Audit yapılacak işlemlerin süzme seçenekleri gayet yeterli. Raporlama ve alarm sistemi oldukça esnek ve zengin. Yapılan işlemlerin öncesini ve sonrasını, sunucunuza fazla yük yüklemeden gerçekleştirebiliyor. En azından teoride ve test ortamında böyle.
Şu anda, bu uygulamanın lisansını satın alma sürecindeyiz. Lisanslama, izlenecek SQL Instance'ı bazında 2.995$ ödenerek yapılıyor. Buna ek olarak, ilk satın alma işleminde bir de zorunlu olarak Maintenance adı altında 599$ tutarında bir ücret ödenmesi bekleniyor. Maintenance ile alınacak hizmet ise, senede ortalama 2-3 çıkan her türlü güncelleştirmeden yararlanma ve 7/24 teknik destek.
Ürünü sadece test sunucusuna kurdum ve denedim, Production sunucumuza kurulumundan sonra da gözlemlerimi sizlerle paylaşmaya çalışırım.
Ekrem Önsoy
Çalıştığım ortamlardan birinde, veritabanlarından bazıları, bazı bankalarla çalıştığımız ve bu çalışmaların sonucunda üretilen kritik verileri barındırıyor. Bu nedenle çeşitli bankaların yaptıkları teftişlerde, kritik verilerin kimler tarafından değiştirildiği, bu verilere kimler tarafından ulaşıldığı, bu trafiğin kayıtlarının tutulup tutulmadığı ve raporlanıp raporlanamayacağı gibi sorular sorulup, taleplerde bulunuluyor.
Bahsini ettiğim ortamda kullanılan SQL Server, Standard Edition olduğundan dolayı, yukarıda bahsini ettiğim teftişlerin talep ettiği gereksinimleri Enterprise Edition'ın Database Audit özelliği ile karşılayamıyoruz. Çünkü bildiğiniz gibi Database Audit özelliği SQL Server'ın sadece Enterprise Edition'ında (ve SQL Server 2008 R2 Datacenter Edition) mevcut.
Bu gereksinim ve ortam nedeniyle ben de araştırmaya koyuldum. Birçok uygulama ile karşılaştım, SQL Server (>=2008) Enterprise Edition'ın Database Audit özelliğini taklit edebilen sadece bir uygulama bulabildim. Bu da, yazının başlığını da oluşturan, Idera firmasına ait olan SQL Compliance Manager isimli uygulama.
SQL Compliance Manager, DML işlemlerinin yanı sıra, kendini diğer benzeri ürünlerden SELECT işlemlerini de kayıt altına alarak ayırıyor. Çok ayrıntılı bir şekilde Auditing yapmak mümkün. Tablo ve Alan bazında Audit işlemi yapılabiliyor. Audit yapılacak işlemlerin süzme seçenekleri gayet yeterli. Raporlama ve alarm sistemi oldukça esnek ve zengin. Yapılan işlemlerin öncesini ve sonrasını, sunucunuza fazla yük yüklemeden gerçekleştirebiliyor. En azından teoride ve test ortamında böyle.
Şu anda, bu uygulamanın lisansını satın alma sürecindeyiz. Lisanslama, izlenecek SQL Instance'ı bazında 2.995$ ödenerek yapılıyor. Buna ek olarak, ilk satın alma işleminde bir de zorunlu olarak Maintenance adı altında 599$ tutarında bir ücret ödenmesi bekleniyor. Maintenance ile alınacak hizmet ise, senede ortalama 2-3 çıkan her türlü güncelleştirmeden yararlanma ve 7/24 teknik destek.
Ürünü sadece test sunucusuna kurdum ve denedim, Production sunucumuza kurulumundan sonra da gözlemlerimi sizlerle paylaşmaya çalışırım.
Ekrem Önsoy
Kaydol:
Kayıtlar (Atom)