Azure SQL veritabanının versiyonunu v11'den v12'ye yükseltmek

Merhabalar,

Haftasonu Azure SQL Database sunucumuzun v11'den v12'ye sürüm yükseltme (Upgrade) işlemini yaptım. Bu deneyimi sizlerle de paylaşmak sitedim.

v12 versiyonunda, birçok özellik eklendi. Temel olarak amaç, buluttaki SQL veritabanlarını kendi sunucularımızda kullandığımız özelliklerle kullanabilmemiz, en azından olabildiği ölçüde. Çünkü sonuçta Azure SQL veritabanlarını veritabanı bazında yönetebiliyoruz, Instance veya sunucu bazında değil. Bu nedenle illa ki birebir aynı olmayacaklardır. Bunun yanında, Row Level Security veya Data Masking özelliklerinde gördüğümüz gibi SQL Server'ın yeni versiyonunda gelecek olan özellikler ilk olarak Azure SQL Veritabanlarında kullanıma açılıyor. Bir taraftan da bu özellikler olgunlaşmış oluyor. Neyse, konumuza dönersek, öncelikle Azure SQL veritabanınızın versiyonunu, kendi sunucularımızda kullandığımızdaki gibi aşağıdaki şekilde ile bulabilirsiniz:

Eğer versiyon v11 ise, o zaman bir sonraki kontrolümüze, yani eski (Retired) Tier'lardan herhangi bir veritabanınızın olup olmadığı kontrolüne geçebiliriz. Eski Tier'lar derken kastettiğim Web ve Business Tier'ları, v12'ye sürüm yükseltme için bu Tier'ları terk etmeniz gerekiyor.

Eğer yukarıdaki Pricing Tier listesinde Web veya Business Tier'larından veritabanlarınız varsa, o zaman v12'ye Upgrade işlemini yapmaya devam edemezsiniz. Ya bu veritabanlarının Tier'ını Basic, Standard veya Premium olarak değiştireceksiniz veya benim gibi işe yaramayan eski Tier'dan kalma veritabanlarınızı silersiniz. Bu gereksinimi de tamamladıktan sonra sürüm yükseltme işlemine devam edebilirsiniz.

Sürüm yükseltme işlemini portal.azure.com adresinden yapabilirsiniz. Fakat bu işi yapmadan önce hazırlık ve planlama için bu makaleyi okumanızı tavsiye ederim. Temel olarak bilmeniz gereken ise, Sürüm yükseltme işleminin saatler ve günler aralığında sürebilecek olma olasılığı ve bu süreçte veritabanlarınız Online olarak kalacak olsa bile bazı yönetimsel kısıtlarla karşılaşacak oluyor olmanız. Bunun yanında şayet varsa geo-replikasyonu da sürüm yükseltme işleminden önce kaldırmanız, sonrasında tekrar kurmanız gerekiyor. Tüm bunlardan sonra (en azından 08 Haziran 2015 tarihi itibariyle) şu yolu takip ederek sürüm yükseltme işlemini gerçekleştirebilirsiniz.

Sol taraftaki menüden Browse'a tıklayın, ardından SQL Servers ve sonra da sağ tarafta çıkan Azure SQL veritabanlarınızı barındıran ve sürüm yükseltme işlemini yapmak istediğiniz sunucuya tıklayın.

Ekran sağ tarafa genişleyecek ve karşınıza aşağıdaki gibi bir ekran çıkacak. Burada "Server version" kısmında v12 görüyorsunuz, çünkü ben bu ekran görüntüsünü sürüm yükseltme işleminden sonra aldım. Sizin senaryonuzda burada v11 yazıyor olacak. En azından v11'den v12'ye sürüm yükseltme işlemi esnasında.

Sürüm yükseltme işlemine devam etmek için "Latest SQL database update" etiketli düğmeye tıklayın.

Eğer eski Tier'lardan kalma (Retired) bir veritabanınız yoksa o zaman karşınıza aşağıdaki gibi bir ekran çıkacaktır. Sürüm yükseltme işlemini gerçekleştirmek bu işlemi yapıyor olduğunuz sunucunun adını teyit etmek için "TYPE THE SERVER NAME" metin kutusuna yazmanız gerekiyor. Yani yeni bir sunucu oluşturmuş veya sunucunun adını değiştirmiş olmuyorsunuz, sadece teyit için varolan ve Upgrade etmek istediğiniz sunucunuzun adını giriyorsunuz. Sürüm yükseltme işlemini gerçekleştirmek için sunucu adınızı eksiksiz olarak girdikten sonra aşağıdaki OK düğmesine tıklayın.

Yukarıdaki ekranda, önceden de değindiğim gibi bu işlemin duruma göre saatler ve hatta günler sürebildiğine dair bir mesaj göreceksiniz. Fakat örneğin benim senaryomda v11'den v12'ye sürüm yükseltme işlemi 30dk içinde tamamlandı.

Sevgiler,
Ekrem Önsoy

DMV: sys.dm_db_persisted_sku_features

Bazı projelerde veya senaryolarda bazı veritabanlarını değişik SQL Server Edition'ları arasında taşımamız gerekiyor. Örneğin bazı kurumlarda bilinçsiz bir şekilde SQL Server Evaluation Edition, Enterprise Edition veya Datacenter Edition (2008 R2) Instance'ları kurulmuş olabiliyor. Bu sistemleri incelediğimizde ve ilgili yöneticilere bu konuda bilgi verdiğimizde, lisans maliyetlerini duyduklarında "bizim buna ihtiyacımız yok, daha düşük bir Edition da kullanabiliriz eğer işimizi görecekse" diyebiliyorlar. Çünkü Enterprise Edition ile örneğin Standard Edition arasındaki lisans maliyetleri arasında çok fark var ve bazı şirketler için bu farkı her ay gereksiz bir yere ödemek mantıksız geliyor, haklı olarak...

Böyle durumlarda, yani daha yüksek seviyedeki bir Edition'daki bir Instance'tan daha düşük seviyedeki bir Edition'daki Instance'a veritabanı taşıyacakken dikkat etmemiz gereken çok kritik bir konu var. Taşıyacağımız veritabanında sadece yüksek seviyedeki bir Edition'da kullanılabilecek bir özellik kullanılmışsa, bu veritabanını bu haliyle daha düşük bir seviyedeki bir Edition'a taşıyamayız. Bir örnekle devam edelim.

Örneğin ISTANBUL\Marketim isimli bir SQL Server 2012 Enterprise Edition Instance'ımızdaki Table Partitioning özelliğini de barındıran Arsiv_2013 isimli veritabanımızı bir başka SQL Server 2012 Standard Edition Instance'ımıza taşıyamayız. Çünkü Table Partitioning sadece Enterprise Edition'larda olan bir özelliktir ve Standard Edition'larda bu özellik kullanılamamaktadır.

SQL Server bize bunu, Database Restore'un bitirilme, yani Database Recovery aşamasında bildirecektir. Yani siz ilgili veritabanının, yine örneğimiz üstünden gidersek Enterprise Edition Instance'ından yedeğini alırsınız ve hedef SQL Server Instance'ında Restore etmeye de başlayabilirsiniz. Recovery aşamasına kadar sorun da çıkmaz, fakat Recovery aşamasında SQL Server, veritabanının herhangi bir üst Edition özelliği taşıyıp taşımadığına bakar ve eğer böyle bir şey varsa, o zaman Restore'unuz hata verir ve tamamlanamaz.

Bu kontrolü en son aşamada yapmasının nedeni ise, örneğin bir Enterprise Edition özelliğini Database Backup aldıktan sonra yapabileceğiniz gerçeğidir. Şöyle düşünün, bir Enterprise Edition, Evaluation Edition veya Developer Edition Instance'ında bir veritabanı oluşturuyorsunuz, bunun Full Database Backup'ını alıyorsunuz, sonra bir tablodaki veriyi sıkıştırıyorsunuz (ki bu da Enterprise Edition özelliğidir) ve sonra bu değişikliği de barındıracak bir Transaction Log yedeği alıyorsunuz. Bu Full Database Backup'ı hedef Standard Edition Instance'ınıza NORECOVERY modunda Restore ettiğinizde, henüz Recovery işlemi tamamlanmadığından sorun olmayacaktır; o son aldığınız Transaction Log yedeğini de NORECOVERY modunda Restore ettiğinizde yine hata almazsınız, çünkü veritabanı hala Recovery işlemini yapmadı; fakat veritabanını RESTORE DATABASE dba_test komutuyla Recover etmeye kalktığınız anda aşağıdaki hataları alacaksınız.


Msg 3013, Level 16, State 1, Line 1
RESTORE DATABASE is terminating abnormally.
Msg 909, Level 21, State 1, Line 1
Database 'dba_test' cannot be started in this edition of SQL Server because part or all of object 'table_adi' is enabled with data compression or vardecimal storage format. Data compression and vardecimal storage format are only supported on SQL Server Enterprise Edition.
Msg 933, Level 21, State 1, Line 1
Database 'dba_test' cannot be started because some of the database functionality is not available in the current edition of SQL Server.

İşte böyle bir senaryoda, yani bir üst Edition'dan alt bir Edition'a veritabanı taşıma işiniz olduğunda, özellikle de boyut olarak büyük veritabanlarında, taşıma işlemi öncesinde ilgili veritabanlarını sys.dm_db_persisted_sku_features isimli DMV ile sorgulamanızda fayda var. Bu DMV size, diğer Edition'larda olmayıp ilgili veritabanında kullanılmış olan özellikleri raporlayacaktır. Bu sayede, özellikle de gerçekten aktif olarak kullanmadığınız bir özellik varsa, bu özelliği kapatıp taşıma işleminizi  başarıyla gerçekleştirebilirsiniz. Eğer gerçekten vazgeçemeyeceğiniz bir özellik mevzu bahis ise de, o zaman ilgili yöneticilerle bunu masaya yatırmanız gerekecek.

Örnek sorgu:
SELECT * FROM sys.dm_db_persisted_sku_features

Ekrem Önsoy

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