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...