SQL Agent Job ve Proxy Account

6. December 2010

Paketimizi bilgisayarımızda tasarladık diyelim. Sıra server'a aktarıp günlük olarak çalıştırmaya geldi. Normalde SSIS paketleri bir sürü farklı yöntemle zamana bağlı çalıştırılabilir. Bu standart Windows Scheduled Tasks ile BAT şeklinde, programatik olarak olabilir ya da SQL Agent vasıtasıyla olabilir. Bu yazımızda SQL Agent vasıtasıyla paketleri nasıl çalıştıracağımızı göreceğiz. Mevcut senaryomuzda dosya sisteminde bulunan bir SSIS paketini nasıl zamanlanmış görev olarak kaydedeceğimizi inceleyelim.

Öncelike SQL Agent ile SSIS paketini zamanlamak için, SQL Agent servisinin çalışır olduğundan emin olmamız gereklidir. SQL Server Management Studio (SSMS) ile SQL Server'a bağlandıktan sonra en altta bulunan SQL Server Agent'ın üzerine geliyor ve sağ click, Start diyoruz.

Çalıştırmak için bize sorduğunda Evet diyoruz. (Dikkat! bazen bu mesaj kutusu zırvalayıp ekranın arkasına kaçabiliyor, odaktan kayboluyor. )

 

Sistem çalışmaya bağlayınca kırmızı olan simge, yeşile dönüyor. Eğer sizin bilgisayarınızdaki simge zaten yeşil ise yukarıdaki başlatma işlemini yapmak zorunda değilsiniz.

 

Hemen Jobs isimli klasörün üzerine sağ click yapıp New Job diyoruz.

 

Önümüze aşağıdaki gibi bir pencere açılacaktır.

Pencerenin sağ tarafında çeşitli sekmeler bulunur. Bunlar sırasıyla:

General: Job'un adı, açıklaması, sahibi, kategorisi gibi genel özelliklerinin belirtildiği yer.

Steps: Job'un alt adımlarının bulunduğu yer. Burada adım adım job2un ne yaptığını belirliyoruz.

Schedules: Job'un çalışma zamanlarını belirlediğimiz yer.

Alerts: Job çalışması sırasında makina üzerindeki koşullardan biri sağlandığında uyarı işlemleri için kullanılır. (Örn: Not Enough Resources (Yeterli kaynak yok), Fatal Error vb. Event log'a yazılmasını sağlıyor.) (Detaylı bilgi için İngilizce bir kaynak: http://www.simple-talk.com/sql/database-administration/sql-server-alerts-soup-to-nuts/ )

Notifications: Job tamamlandığında çeşitli uyarı veya mesaj yollayan işlemlerin yaratıldığı yer. (Operator, Net Send vb.)

Targets: Agent üzerinde Çoklu-Server yönetimi yaptığınızda anlam kazanan bir uygulama. (Daha fazla bilgi için İngilizce bir kaynak: http://www.yaldex.com/sql_server_tutorial_3/ch08lev1sec5.html )

 

Steps sekmesine gelerek paketi çalıştıracak olan adımı New düğmesine basarak tanımlayalım.

Yeni Adım oluşturma penceresinde, Step Name kısmına açıklayıcı bir isim yazıyor ve Type kısmında SQL Server Integration Services Package seçiyoruz. Run as kısmı ise paketi kimin yetkisiyle çalıştırılacağını belirlediğimiz yer. Normalde paket SQL Server Agent servisini çalıştıran kullanıcı ile çalıştırılır.

SQL Server Agent servis kullanıcını görmek için servisleri açıp bakabilirsiniz:

Ya da alternatif olarak belirleyeceğiniz Vekil kullanıcı hesabı (Proxy Account) üzerinden çalıştırılır. Vekil kullanıcı üzerinden çalıştırılmak istenmesinin sebebi ana sebebi ise SQL Server Agent servis kullanıcısını, paketiniz içerisinde bağlandığınız çeşitli veri kaynaklarına erişebilir hale getirme zorunluluğundandır. Bu pek tercih edilen bir durum değildir. Bu nedenle Vekil Kullanıcı Hesapları (Proxy Account) kullanılır. Proxy Account ile sanki bir paketi o kullanıcı çalıştırıyormuşcasına çalıştırmanıza imkan tanır.

 

Hatırlarsanız, paketi dosya sistmeinden çalıştıracağımızı söylemiştik. İşte bu ayarı ise Package Source üzerinden belirliyoruz.

Ardından alt taraftaki bölümden paketimizi bulup seçiyoruz.

 

Aslında bu noktada işlemimiz tamamlanıyor ancak çok detaya girmeden diğer sekmelerin de ne işe yaradığıyla ilgili olarak sizlere bir iki faydalı bilgi sunmak isterim.

Configuration Tab, eğer paketinizi belirli bir config dosyasındaki parametrelere göre çalıştırmak isterseniz onları ekleyeceğiniz yer.

Command Files, SSIS paketi ile birlikte çalışacak olarak komut dosyalarını belirlediğiniz yer. Aslında SSIS paketini çalıştıran özel bir uygulama var. DTEXEC. Siz bir job tanımladığınızda, o job DTEXEC.exe'yi belirli bir sentaksa göre çağırır, bu sentaksı değiştirmek veya diğer özelliklerini de kullanmak istiyorsanız buraya ilgili komutların olduğu dosyayı yükleyebilirsiniz. Bunun en büyük faydası ise şu: Yeniden bir job tanımlamanız gerektiğinde bunu farklı bilgisayarlarda işleme sunmak istiyorsanız tek bir komut dosyaı oluşturuyor ve yüklüyorsunuz. (Detaylı bilgi için ekteki kitabın 235'ten sonraki sayfalarına bakabilirsiniz: http://www.amazon.com/Hands--Microsoft-Server-Integration-Services/dp/0072263199/ref=sr_1_1?s=books&ie=UTF8&qid=1281903315&sr=1-1 )

Datasources sekmesinde seçmiş olduğunuz paketin içinde bulunan bağlantı bilgilerini görebilir ve değiştirebilirsiniz.

Execution Options sekmesi oldukça önemli bir sekme aslında. Burada paketi herhangi bir validasyon sorunu bulunduğunda çalıştırmamayı, sadece valide etmeyi, aynı anda çalışma özelliğini değiştirmeyi, paketi checkpoint özelliği ile çalıştırmayı seçebilirsiniz. Buradaki belki de en önemli özellik ise bence "Use 32 bit Runtime" (SSIS'i 32 Bit Olarak Çalıştırma) özelliği. Son zamanlarda neredeyse çoğu server artık 64bit işletim sistemi ve 64 bit SQL server kurulu. Ancak 64bit sistemlerin SSIS paketleri üzerinde kötü bazı sonuçları var. Mesela Access,Excel veri kaynaklarını kullanamıyor, Script özelliğini devre dışına almak zorunda kalıyorsunuz. İşte bunlardan feragat edemeyecek bir ETL tasarımınız var ise, paketi sanki 32Bitmiş gibi çalıştırmanıza yarayacak bir özellik olarak çok faydalı oluyor. (Bu dtexec.exe'nin 64bit'i yerine 32bit versiyonun çalışması anlamına geliyor)

Loggin sekmesi, Paket çalışması sırasında bir loglama özelliği olsun istiyorsanız bu loglama işlemini tanımladığınız yer.

Set Values Sekmesi çalışma sırasında paketin özelliklerinden bazılarına vereceğiniz değeri atadığınız yerdir. Burada paket dğeişkenlerine de çeşitli değerler atayabilirsiniz. Örneğin: Property Path: \Package.Variables["Mali Yil"].Value, Value ise 2010.

Verification sekmesinde, paketin imzalanmış olma zorunluluğunu veya çeşitli diğer özelliklerini, belirlediğiniz build numarası, paket id'si gibi çalıştırmanıza yarar. (Daha fazla bilgi için İngilizce makale: http://munishbansal.wordpress.com/2009/05/15/digital-signing-a-ssis-package-sql-server-2005-integration-services-security/ )

Command Line sekmesinde ise en son olarak DTEXEC.Exe'ye gönderilecek olan komutun bulunduğu yeri görebilirsiniz. Bazı durumlarda paketin Protection Level'ı "Encrypt sensitive with password" ise yani paket girilen şifreleri belirlemiş olduğunuz bir anahtar üzerinden şifreleyecek şekilde tasarlanmışsa buradaki komutu "Edit the Command line manually" olarak değiştirip /DECRYPT "ŞİFRENİZ" şeklinde bir ek yapmanız gereklidir.

 

Son olarak dilerseniz Job adım penceresindeki ikinci sekme olan "Advanced" sekmesine giderek oradaki özelliklere de bir göz atalım.

Burada öğeler aşağıdaki gibidir:

On Success Action: Eğer job adımı başarıyla tamamlanırsa bir sonraki işlemin ne olacağını belirlediğiniz yerdir. Burada bir sonraki Job adımına geç (Go To Next Step), Job'un tamamını başarıyla tamamlanmış olarak belirle ve sonraki adımları çalıştırma (Quit the Job reporting Success) veya aynı işlemi hata olarak raporlayarak job'u bitir (Quit the Job reporting Failure)

Retry Attempts: Eğer bir şekilde bu adım başarısız olursa bir kaç kez daha çalıştırmayı deneyeceğinizi belirlediğiniz yer.

Retry Interval: Dakika cinsinden, başarısızlık halinde yeniden denemeden önce beklemesini istediğiniz süre. Bu iki opsiyon genelde eğer uzak bir veri kaynağına bağlanıyorsanız hatlarda veya server'da oluşabilecek bir hata nedeniyle erişiminiz kısıtlanmışsa sıklıkla kullanacağınız bir özellik olacaktır.

On Failure Action: Eğer job adımı başarısız olmuşsa ne yapılması gerektiğini belirlediğiniz yer. "On Success Action" özelliğinde olan durumlarla benzer seçimler.

Output File: Job adımı çalıştığında çalışma zamanı loglarını tutmak istediğiniz dosyanın yolu. Eğer "Append Output to Existing File" seçilmezse her çalışmada dosya silinir ve yeniden oluşturulur.

Log to Table: Job adımı loglarını dosya sisteminde değil de aynı zamanda bir veritabanında da tutmak isterseniz seçmelisiniz.

Include Step Output in history: Job adımına ait çıktıları Job'un tarihçesince tutulmasını istiyorsanız kullanacağınız alan. Ben genellikle seçiyorum. Herkese de tavsiye ederim.

 

Evet job işlemi tamamlandıktan sonra dilerseniz biraz da Proxy Account kullanımına ve nasıl tanımlanacağına ilişkin bir bölümle yazımıza son verelim.

Proxy Account aslında sql server üzerinde bir çok farklı işlemi yapmak üzere tasarlanmış vekaleten yapılan işlemeri gerçekleştirmek için kullanılan bir metottur. Peki neden Proxy Account kullanıyoruz?

Biliyorsunuz ki bazı senaryolarda veriye eriştiğiniz yerlerde özel bir kullanıcının yetkisi gerekir. Bu güvenlik açısından da daha yönetilebilir bir özelliktir. Varsayalım ki network altında bir klasörden bir excel dosyası okuyoruz. Bu excel dosyasına erişebilmek için o klasöre yetkiniz olması gereklidir. Ancek paketi siz değil de SQL Server Agent kullanıcısı çalıştırdığında problem oluşur. SQL Server Agent servis kullanıcısı lokal bir kullanıcıdır. Yani sadece SQL Server'ın kurulu olduğu makinada tanımlıdır. Domain Network yetkisine saihp değildir. Bu nedenle ya SQL Server Agent Servis kullanıcısını domain kullanıcısı olarak belirler ve onunla çalıştırırsınız ya da SQL Agent servisi kendi kullanıcısı ile hayatına devam ederken proxy account kullanırsınız.

Benzer bir şekilde, Windows Authentication ile bağlandığınız veri kaynakları varsa yine bir yetki problemiyle karşılaşırsınız. Ve hatta Windows Authentication ile değil de Server Authentication ile bağlanıp da paketinizin protection level'ını user key ile encrypt ederseniz keza çalışma zamanında onu decrypt edecek olan kullanıcın da aynı olması gereklidir. Keza bu Proxy Accounta tekabül etmektedir.

(Not: Aşağıdakine benzer bir hata alıyorsanız proxy account ile paketi encrypt eden kullanıcı aynı değildir anlamına geliyor. Bu durumda paketi proxy account ile encrypt etmelisiniz:

Message
Executed as user: DOMAIN\USER. …n 9.00.3042.00 for 64-bit Copyright (C) Microsoft Corp 1984-2005. All rights reserved. Started: 4:33:43 PM Error: 2008-09-15 16:33:43.32 Code: 0xC0016016 Source: Description: Failed to decrypt protected XML node "DTS:Password" with error 0x8009000B "Key not valid for use in specified state.". You may not be authorized to access this information. This error occurs when there is a cryptographic error. Verify that the correct key is available. End Error Error …
)

 

Genel itibariyle bu güne kadar sorunsuzca kullandığım senaryo, proxy accountun domain seviyesinde bir kullanıcı olması ve paketlerdeki veri kaynaklarına bağlantı Windows Authentication olmak kaydıyla yarattığım senaryoydu. Sayısız projede de bu şekilde hem güvenlikten ödün vermeden maintenance yükünü azaltmış hem de süreci basitleştirmiştim.

Şimdi dilerseniz Proxy Account'un nasıl tanımlanacağına gelelim.

Öncelikle SSMS içerisinde bir Creditential yaratmalıyız.

Server içerisinde Security>Creditentials üzerine gelerek New Creditental diyoruz:

Isim verdikten sonra Identity alanında ilgili domain kullanıcısını seçiyoruz ve şifresini giriyor ve yaratıyoruz.

 

Ardından, SQL Agent içerisinde bulunan Proxies klasörüne gelerek sağ click ve New Proxy diyoruz.

Ardından açılan pnecerede Proxy ismini ve bir önceki adımda yarattığımız creditental'i seçiyoruz.

Alt sistemde ise "SQL Server Integration Services Package" seçiyoruz. Eğer istersek pricipal adımından bu proxy'e ekstra özellikler verebiliyoruz, çok lazım değil aslında SSIS için. (örn: Serveradmin)

Bu şekilde işlemlerimizi tamamladıktan sonra bu proxyile çalıştırmak istediğimiz job adımlarına gidip Run as sekmesinde bu kullanıcıyı seçiyoruz. Böylece o adım artık sanki bu tanımladığımız Proxy kullanıcısı çalıştırıyormuş gibi çalışacak.

 

Daha fazla bilgi için çeşitli kaynakları aşağıda bulabilirsiniz:

http://msdn.microsoft.com/en-us/library/ms139805.aspx

http://support.microsoft.com/kb/918760

http://www.mssqltips.com/tip.asp?tip=1041

http://www.mssqltips.com/tip.asp?tip=1231

Post Operations , ,

Add comment




biuquote
  • Comment
  • Preview
Loading