7 Mart 2011 Pazartesi

Package migration from version 3 to version 2 failed with error 0xC001700A "The version number in the package is not valid. The version number c

HATA:
Package migration from version 3 to version 2 failed with error 0xC001700A "The version number in the package is not valid. The version number cannot be greater than current version number.

Açıklama:
Bir SSIS paketini doğrudan veya dolaylı olarak (örneğin bir toplu işlem dosyası (*.bat) ile) "dtexec" uygulaması kullanarak çalıştırmak isterseniz böyle bir hata ile karşılaşabilirsiniz. Örneğin ben bu sorunla karşılaştığımda, SSIS paketleri SQL Server 2008 versiyonuyla uyumluydu; paketler başka bir sunucudaydı ve paketler toplu işlem dosyaları ile çalıştırılıyordu. Paketler ise başka bir sunucudan UNC yolu kullanılarak (örn: \\...\...\...) çalıştırılıyordu. Yani çalıştırılan "dtexec" uygulaması aslında toplu işlem dosyalarına hangi makineden ulaşılıyorsa o makinedeki "dtexec" uygulaması kullanılmış oluyordu, SSIS paketlerinin bulunduğu sunucudaki "dtexec" değil.

Sorunu araştırırken şunu farkettim, operatörün bağlandığı makinede hem SQL Server 2005 hem de SQL Server 2008 kuruluydu ve operatör toplu işlem dosyasını çalıştırdığında aslında SQL Server 2005 versiyon olan "dtexec" uygulaması çalıştırılıyordu ve "eski yeniyi tanımaz" kuralına uygun olarak 2008 versiyon SSIS paketlerini tanımadığından yukarıdaki hatayı veriyordu.

Windows Environment Variables'ı kontrol ettiğimde SQL Server 2005 yolunun 2008 yolundan önce tanımlandığını gördüm, yani bir uygulama çalıştırılacağı zaman öncelikle 2005'in yollarında aranıyordu uygulama ve "dtexec" uygulaması SQL Server 2005'te de 2008'de de aynı isimle olduğundan dolayı 2005 versiyonu çalıştırılıyordu.

ÇÖZÜM:
Sorunu tespit ettiğimde geçici çözüm olarak SQL Server 2005'in "dtexec" uygulamasının adını "dtexec_" olarak değiştirdim ve artık varsayılan olarak SQL Server 2008'in "dtexec" uygulaması çalıştırılıyordu. Kalıcı çözüm olarak ise şayet gerekmiyorsa SQL Server 2005 tamamen kaldırılabilir (uninstallation). Şayet iki versiyona da ihtiyaç varsa yine ilk çözümde olduğu gibi dosya adı değiştirilebilir.

6 Mart 2011 Pazar

Bir taşıma tecrübesi...

Bu haftasonu, çok önemli üretim veritabanı sunucularımızdan biri olan bir sunucuyu SQL Server 2005'ten SQL Server 2008'e taşıdık. Ayrıca işletim sistemi olarak da Windows Server 2003'ten Windows Server 2008 R2'ye geçmiş olduk. Bu konuda yaşadığımız bazı tecrübeleri sizinle de paylaşmak istedim.

Öncelikle akla gelen "Neden SQL Server 2008 R2'ye veya bu yılın sonunda çıkması beklenen SQL Server 2011'i (kod adı Denali) bekleyip de bu yeni versiyonlara geçiş yapmadınız da gittiniz 2 sene öncesinin versiyonuna geçiş yaptınız?" sorusunu yanıtlayayım da hepimiz rahatlayalım. Bunun nedeni, kullandığımız 3. parti bir uygulama olan Oracle Golden Gate uygulamasının henüz resmi olarak SQL Server 2008 R2'yi desteklememesi ve bu ürünü üretim ortamında kullanmamızın gerektiğidir. SQL Server 2008 R2'nin piyasaya sunulmasından sonra (RTM) 2 sene geçmiş olmasına rağmen hâlâ bu versiyona resmen desteğini açıklamamış olan Oracle'dan haliyle SQL Server 2011 için elini çabuk tutmasını beklemezsiniz. Zaten Golden Gate'i Oracle firmasına satan ve Golden Gate'in hâlâ CEO'su olan Ali Kutay Bey de geçen sene Oracle'a satış sonrası Dedeman'daki Golden Gate toplantısında şöyle demişti: "Golden Gate için artık iki geliştirme ekibimiz bulunuyor, birisi Oracle geliştirme ekibi, diğer ekip de diğer ürünleri destekleyen ekip." Golden Gate uygulamasının Oracle Database, Microsoft SQL Server, IBM DB2, Sybase vb. RDBMS'leri desteklediğini göz önüne alırsak sanırım ne demek istediğim daha net anlaşılır.

Bu taşımada, Detach\Attach ile kaybedilen zamanı kazanmak için başka değişik bir yöntem izlemek istedik. Bu yöntem ile izleyeceğimiz yol aşağıdaki gibi olacaktı:

- Veritabanları kaynak sunucuda OFFLINE duruma getirilir,
- Diskler kaynak sunucudan çekilir,
- Diskler hedef sunucuya gösterilir,
- İlgili diskler, Cluster SQL Server Resource'una bağlanılır (depend),
- Veritabanları hedef sunucuda ONLINE duruma getirilir.

Not: Hedefteki SQL Server sunucusuna önceden aynı disklerin klonları gösterilmiş ve veritabanları Attach edilmiş olmalı (ki bunu başka testler için de zaten yapmış oluyorsunuz) ve ardından da diskler geri çekilmeden önce veritabanları OFFLINE durumuna alınır ve böylece yukarıdaki sıralamış olduğum son adım gerçekleştirilebilir.

Bu yöntemi iki kere test ettik. İkisinde de ACCESS VIOLATION sorunlarıyla karşılaştık ve bu sorun da SQL Server'ın Dump almasına neden oldu. Bu sorunu araştırırken, sorunu veritabanı veri veya log dosyalarının disk kökünde (root) bulunduğu disklerde yaşadığımızı fark ettik. Diskler Mountpoint. Şayet diskin içinde bir klasör varsa ve dosyalar klasörün içindeyse, o zaman bu sorunu yaşamadan veritabanlarını ONLINE duruma aldığımızda veritabanlarının hem otomatik olarak SQL Server 2005'ten 2008'e sürüm yükseltmesi (upgrade) yapıldığını gördük, hem de başarıyla ONLINE duruma geldiklerini. Maalesef tüm disklerdeki tüm dosyaların (30 kusür diskteki yüzlerce dosyadan bahsediyorum) yerlerini değiştirmek ve testi tekrarlamak için zamanımız olmadığından dolayı bu yöntemden kısmen vazgeçtik ve aşağıdaki yöntemi izledik:

- Veritabanları kaynak sunucuda OFFLINE duruma getirilir,
- Diskler kaynak sunucudan çekilir,
- Diskler hedef sunucuya gösterilir,
- İlgili diskler, Cluster SQL Server Resource'una bağlanılır (depend),
- Veritabanları hedef sunucuda Attach edilir.

İşin garip tarafı, dosyalar Mountpoint'lerin kök dizininde de olsa elle Attach ettiğimizde herhangi bir sorunla karşılaşmamamıza rağmen, bunu SQL Server'daki OFFLINE durumda olan veritabanını ONLINE'a alarak SQL Server'a yaptırdığımızda ACCESS VIOLATION hatası almamızdı. Bunu Microsoft mühendisleriyle de paylaştık, fakat onlar da mantıklı bir açıklama bulamadı. Muhtemelen sorunu Amerika'ya taşırsak belki bir sonuç alabilirdik, ama buna da vakit yoktu. Ayrıca Microsoft'taki arkadaşlardan önceden bu tür bir sorunla karşılaşılmış senaryolar hakkında araştırma yapmalarını da rica ettik ve bizimki gibi yaşanılan bir senaryo daha bulduk (maalesef bunu bizden önce birileri bir kere denemiş anlaşılan!), fakat o sorun da yüzeysel olarak kapatıldığından ve net bir çözüm üretilemediğinden dolayı o senaryo da bizim için bir çözüm olmadı.

Bu geçiş için sabaha kadar ofisteydim ve bu sabah 9 gibi eve gelebildim. Biraz uyudum, ama şimdi Log Shipping ve Golden Gate ile ilgilenmem gerekiyor...