Bu makalede veritabanı mdf file uzantısının olduğu disk yolunu değiştirmek istediğimizde karşılaşmış olduğumuz bir sorun üzerine makale yazma gereği duydum.
Veritabanı dosyalarımızın koştuğu disk dolmaya başladığında disk genişletme adımı için boş bir LUN alan tahsis edilir.
İlgili disk üzerine gelip sağ tıkladığımızda Extend Volume.. denilir.
Genişletmeye çalıştığımız disk üzerinde aşağıdaki hata mesajıyla karşılaşılır.
İlgili hatayı araştırdıktan sonra hata sebebinin veritabanının formatlama şeklinden kaynaklandığını görmüş olduk. Aşağıdaki resimde de görüldüğü gibi Allocation unit size değeri 8KB olarak görülmektedir. Buda disk’in destekleyeceği maksimum alanın 32 TB olacağını göstermektedir.
Not: Sql Server verileri diskten 64 KB’lık extend’ler şeklinden alır. Bunun için disk formatlanmasının 64 KB olarak seçilmesi gerekmektedir. Çünkü 8 KB, 8 defa diske gitmesine sebep olacaktır. Buda performans anlamında bize sıkıntılara sebebiyet verecektir.
Eğer AlwaysOn yapısında olan senkron veritabanlarımız aynı disk altındaysa bir süreden sonra veritabanının büyümemesine sebebiyet verecektir. Bunun için veritabanının farklı bir disk yolu altında olması tavsiye edilir..
Not: AlwaysOn yapılarında veritabanı farklı disk yolu altındada senkron bir şekilde çalışmaktadır. Ama primary sunucusunda farklı bir klasörde data file eklendiği zaman secondary sunucusunda bulunan veritabanı suspend moduna düşer. İki sunucuda aynı disk yolu ve uzantısının bulunması gerekmektedir. Ayrıca failover işleminden sonra eski primary sunucusunun suspect moda düşmesine sebebiyet verebilir.
Aşağıdaki resimde NTFS disk formatlama biçimlerinin maksimum destekleyeceği disk kapasiteleri görülmektedir. Aşağıdaki resimdede 8 KB’ın 32 TB’ı desteklediğini görmekteyiz. Resimdede dikkat ederseniz 64 KB olarak desteklenen formatlanma biçiminin 256 TB’a kadar disk boyutunu destekleyeceğini göstermektedir.
Şimdi yukarıdaki işlem için oluşturmuş olduğumuz senaryoya değinelim. Disk boyutunun genişletilemediği sunucunun 2. Secondary sunucusu olduğunu söylemek gerekir. Sistemimiz 3 node ile çalışmakta 1 primary ve 2 secondary sunucusu olarak çalışmaktadır. Değişim işlemi yapacağımız sunucunun Disaster recovery (DR) sunucumuz olan S3 sunucumuz olduğuna değinelim. Şimdi yapacağımız işlemin senaryolarına değindikten sonra gerçek sistem üzerinde hangi bölümlere dikkat edeceğimizi ekran resimleriyle göstermiş olacağız. Örneklerime AdventureWorks2014 üzerinde yapmaya çalışacağım.
Yapılacak Adımlar:
- 1-) Full backup disk yolu değiştirilecek S3 sunucusuna atılır.
- 2-) Primary node üzerinde log backuplar durdurulur. Çünkü primary sunucu üzerinden veritabanı çıkarılır. Bu sebepten log dosyalarımız farklı bir uzantısına backup alınmasın diye daha sonra log backuplar restore yapılınca log dosyalarının bulunmamasına sebep olabilir.
- 3-) İlgili DB veya DB’ler Primary AG’den remove edilir. Bu adımdan önce AlwaysOn failover mode durumu Manuel duruma getirilir. Herhangi bir sıkıntı anında failover olmasın sistem.
- 4-) Secondary Node üzerindeki ilgili DB’lerin restoring mode geçtiğinden emin olunur.
- 5-) Secondary Node’lar üzerinde restore yapılmayacak olan (S1 veya S2) Node üzerinde hayatına devam edebilmesi için ilgili DB’ler AG’ye Primary ‘Skip İnitial Data synchronization‘ seçeneği ile eklenir. Daha sonra failover manuel moddan çıkarılabilir. 2 node’lu sistem kullanıyorsanız manuel’de kalması tavsiye edilir.
- 6-) Secondary Node (S1-S2) Altındaki AG’den ilgili database’ler join edilerek database’ler bağlanır.
- 7-) İlk iki node senkron olduktan sonra Log backuplar tekrar aktif edilecek.
- 8 -) İşlem yapılacak secondary node üzerinde (S3) Restoring Database silinir.
- 9-) 64 KB formatında tahsis edilen yeni diski harfi gerçek sistem disk harfinden farklı olacak şekilde değiştirilir. Kullanılmayan bir disk alanının tahsis edilmesi gerekmektedir. Bu adım başlangıçta da yapılabilir.
- 10-) Yeni alınan diskin harfi Eski harf ile aynı olacak şekilde değiştirilir.
- 11-) İlgili database’lerin yeni disk üzerinde Full backup restore’ları başlatılır.
- 12-) Full backup’ın restore’ı bittikten son log backup durdurulur. Diff backup primary’den alınır. Amacımız Diff sonrası yeni bir log üretmemesi. Secondary’e aktarılacak ve restore edilecek.
Backup restore işlemlerinde Full backup ve Diff backup’ların kullanılması işlemi hızlandıracaktır.
Önemli olan bazı yerlere ekran resimleriyle değinmiş olalım.
2. adımda söylendiği gibi işlem yapılacak tüm sunucularda log backup komutunda ilgili veritabanı çıkartılır. Çünkü log backup alınırsa diğer sunucularda bulunan veritabanı üzerine restore edilmesi gerekmektedir. Gerçek sistemde yaşadığım sıkıntıdan primary sunucusu üzerinde AG den çıkarttığımızda veritabanı log backup’ı farklı bir uzantıya aldığı için restore işlemleri sırasında sıkıntı yaşayabilirsiniz.
3. adımda AG altında bulunan ilgili veritabanı AG’den çıkartılır. Bu işlem sonrasında veritabanımız primary üzerinde çalışmaya devam edecektir.
4. adımda diğer sunucular üzerinde AG’den çıkarılan veritabanının Restoring modda olduğu kontrol edilir.
5. adımda veritabanı tekrardan ‘Skip İnitial Data synchronization’ yapısıyla AlwaysOn yapısına dahil edilir. Kontrollü şekilde yapmak için Join only yöntemi kullanılmaz.
Bu yapı ile veritabanı hiçbir şey yapılmadan tüm sunucularda AG’ye dahil edilir. Şunu sorabilirsiniz veritabanı başlangıç olarak AG’den çıkarılmadan 3. Node AG’den çıkarılsaydı olmazmıydı. Olurdu burada Register’a kaydedilen AG yapımızda bozulma olabilir. Buda tüm AG yapısının resolving moduna girmesine sebebiyet verebilir. Bunun için bu yol izlenmektedir.
6. adımda 3. Node üzerinde işlem yapacağımız için ikinci Node AG’ye dahil edilir. S2 sunucusunda AG üzerine gelinip Join to Availability Group.. işlemi yapılmaktadır.
7. adımda log backup tekrardan aktif edilir. İlgili database log backup komutundan çıkarılır. 2. Adımda eklenen veritabanı tekrar silinir. İkinci sunucuda sorun yaşamamak için bu durum kullanılır.
Yukarıdaki adımlardan sonra 3. Node’da veritabanı silinir yeni tahsis edilen disk ismi gerçek sistemle aynı olacak şekilde yapılandırılır. Norecovery modda 64 KB formatında oluşturulmuş yeni disk altına restore işlemi gerekmektedir.
Dikkat ederseniz restore yapmadan önce disk isim değiştirilir. Önceden yanlış formatlanmış olan disk ismi kullanılmayan bir isimle değiştirilir. Gerçek sistemdeki disk ismi ise yeni diske tahsis edilir.
Ful backup restoring modda yüklendikten sonra tekrardan primary sonucunda ilgili job altında log backupdan çıkarılır. Gerçek sistem üzerinde diff backup alınıp 3. Node norecovery modda restore işlemi yapılmaktadır.
Daha sonra 3. Node’da restoring modda olan veritabanı AG’ye dahil edilir.
Bu makalede veritabanı mdf file uzantısının olduğu disk yolunu değiştirmek istediğimizde karşılaşmış olduğumuz bir sorun üzerine nasıl işlemlerin yapılması gerektiğini madde madde değinmiş olduk.
Not: mdf ve ldf dosyalarının ismini değiştirmek istediğimizde sayfamızda veritabanı adını değiştirmek makalesinde yapıldığı gibi modify komutuyla değiştirilmektedir. Hatırlatmak adına aşağıdaki komutlar kullanılmaktadır. ELAZIG olarak değiştirilen veritabanı isminin mdf ve ldf dosyasının ismini değiştirme komutunu görmüş bulunmaktayız.
ALTER DATABASE ELAZIG MODIFY FILE (NAME = 'DENEME', FILENAME = 'E:\DATA\ELAZIG.mdf');
ALTER DATABASE ELAZIG MODIFY FILE (NAME = 'DENEME_log', FILENAME = 'C:\Program Files\Microsoft SQL Server\MSSQL14.TEST\MSSQL\DATA\ELAZIG_log.ldfBaşka bir makalede görüşmek dileğiyle..
“Yürüyüşünde ölçülü ol, sesini yükseltme; çünkü seslerin en çirkini eşeğin anırmasıdır.”Lokman-19
