SSIS Audit Component

12. January 2010

SSIS Audit Component

Bugün Datawarehouse sistemlerinin en önemli kavramlarından biri de "Surrogate Keys" adı verilen alanlardır. (Söz meclisten dışarı: Çoğu kişi aslında kavramı biliyor olabilir ama isminin "Surrogate Keys" olduğunu yakın bir zamanda öğrendim ben de)

"Surrogate Keys" tanımını biraz açarsak, bu alanlar tablolardaki doğal anahtarların ikamesidir. Ya da bir başka deyişle veriyi diğer bir açıdan gruplamamızı sağlar. Ona farklı bir betimleme getirir.

En en en basit örneğini vermek gerekirse, profesyonel veri ambarlarıyla çalışmış olan kişiler genellikle kayıtlarda insertdate, insert_id vb. alanlar görürler. İşte bu alanlardır diyebiliriz. (Tam kavramı karşılamıyor olabilir ama öyle kabul edin ya)


Velhasılkelam, SSIS içerisinde bize insert_id vb. alanları kolayca oluşturmak amacıyla bir araç bulunmaktadır. Bu componentin ismi "Audit Component"'dir.

Audit Component, aktarım anında mevcut pipeline içerisine Execution Instance GUID, ExecutionTime, Package Name vb. ek bilgiler ekler. Bu bilgiler ne işe yarar diye düşünmeyin. Eğer ki aynı tabloyu farklı zamanlarda farklı SSIS paketleriyle besleyen bir sisteminiz varsa hayati önem taşır.
Bu önemi biraz açalım. (Daha bugün işime yaradı)

Perakende sektöründe büyük ve eski bir yere sahip olan bir müşteri için yaklaşık 15 günde ayağa diktiğim bir veri ambarı içerisinde yıllık yaklaşık 100 milyon veriyi barındıran bir Fact tablosunda bir tarih aralığı için, sistemlerde olan bir hatadan dolayı iki kere veri içeriye atılmıştı. Şimdi Natural Key'ler üzerinden bu durumu öyle kolay kolay çözemezsiniz. Customer_No, Product_No gibi anahtarlarda ne yaparsanız yapın Delete SQL'i içerisinde ayrıştıramazsınız. Her ne kadar Primary Key üzerinden yakalamaya çalışsanız da Identity özelliği de sıralı olmayabilir. İşte bu noktada fact tablosuna eklediğim Execution GUID sayesinde {xxxx-xxxx-xxx-xxxx} olan GUID'li aktarımdan gelen verileri sil diyebildim. Aksi halde o tarih aralığını tamamiyle silip yeniden içeriye atmakla inanılmaz vakit kaybedecek, her ne kadar akşamları index-rebuild etsem de gün içerisinde Index -Fragmentation'u gereksiz yere arttıracaktım ve bu da performans sorunlarına neden olacaktı. Ancak Audit Component hayat kurtardı diyebilirim.

İşte bu özelliğin nasıl yaratıldığına dair bilgiyi de sizlerle payaşmak istedim.

Öncelikle çok basit olan Dataflow Task 3 adet component'ten oluşmakta.
  1. OLEDB Source
  2. Audit Component
  3. OLEDB Destination

Örnekte Adventureworks veritabanından Sales Detail tablosunu Staging DB'de bir tabloya yazmaktayım. Staging DB'deki tabloda ek olarak Audit Componentten gelen alanlar için de yerler bulunmakta. (Tavsiye => Oledb Source'u belirledikten sonra AuditComponent'e balayın ve Audit Componentte eklemek istediğiniz alanları seçtikten sonra OLEDB Source üzerinden eğer ki yeni tablo yaratıyorsanız, yaratın. Çünkü Metadata ile yaratacağından datatiplerini vs o ayarlar CREATE TABLE sorgusunda.)


Aşağıdaki ekrandan gördüğünüz gibi Audit Transformation içerisinde 4 adet audit bilgisini görmektesiniz:
  1. Execution Instance GUID
  2. Package Name
  3. Execution Start Time
  4. Task Name

Benim Best Case'im de bu 4'lüyü kullanmak üzerine genelde.


 


Sonuçta veriyi aktardığınızda ise ilgili tabloda bu alanları dolu olarak görmüş olacaksınız.





Dataflow Components ,

Add comment




biuquote
  • Comment
  • Preview
Loading