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
Microsoft SQL Server ve Microsoft SQL Server ile ilgili diğer uygulamalar, araçlar ve haberlerle ilgili Türkçe içeriği bu günlükte bulabilirsiniz.
24 Ekim 2013 Perşembe
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
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.
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.
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
Etiketler:
Audit,
compliance,
idera,
manager,
teftiş
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.
Etiketler:
Audit,
compliance,
idera,
manager,
teftiş
Kaydol:
Kayıtlar (Atom)

