Çevrimiçi iken SQL Server veritabanını yeni bir diske taşıma

Disk G / Ç ile büyük mücadele veren bir 1.4 TB SQL Server Veritabanı var. Sunucuya tüm sorunlarımızı çözecek yeni bir SSD dizisi kurduk, veritabanını taşımak için en iyi yolu tartışıyoruz. İdeal olarak, kesinti olmadan yapabilirsek, bu en iyisidir. Ancak seçimin, iki saatlik kesinti süresi ile iki günlük düşük performans (örneğin veri kopyalarken) arasında olması durumunda, ikincisi tercih edilebilir.

Şimdiye kadar bulduğumuz çözümler şunlardır:

• Basit kopya. DB'yi çevrimdışı duruma getirin, dosyaları kopyalayın, SQL Server'daki konumları değiştirin ve tekrar çevrimiçi duruma getirin. Kaba rakamlar bunun beş saate kadar süreceğini tahmin ediyor, ki bu gerçekten kabul edilemez, ancak en kolay çözüm.

• Blok düzeyinde kopya. Rsync benzeri bir yardımcı program kullanarak, DB çalışırken dosyaları arka planda kopyalarız. Taşınmaya hazır olduğumuzda DB'yi çevrimdışına alıyoruz, bu yardımcı programı kullanarak farklı bir kopya yapıyoruz, sonra SQL sunucusunu yeni dosyalara yönlendirip çevrimiçi hale getiriyoruz. Burada zamanlama bilinmiyor. 1.4 TB'lık diferansiyel bir analiz yapmanın ve bunu kopyalamanın ne kadar süreceğini bilmiyoruz. Diğer endişemiz, blok düzeyindeki kopyanın SQL Server tarafından okunamayan bazı durumlarda dosyaları bırakması ve zamanımızı harcayacağız.

• SQL geçişi. Yeni diskte yeni bir 1.4 TB SQL veri dosyası oluşturun ve diğer tüm dosyalarda otomatik büyümeyi devre dışı bırakın. Ardından diğer tüm veri dosyalarında DBBC SHRINKFILE (-file_name-, EMPTYFILE) komutunu çalıştırın. Tüm veriler karşılandığında, MDF dosyasını SSD'ye taşımak ve kullanılmayan diğer dosyaları kaldırmak için bir noktada planlanmış bir pencere alacağım. Bunu seviyorum çünkü kesinti süresini en aza indirir. Ancak bunun ne kadar süreceği ve gerçekleşirken performansta bozulmaya neden olup olmayacağı hakkında hiçbir fikrim yok.

Bunu test etmek için herhangi bir yük ve performans ortamımız yok. Stratejilerin evreleme ortamımızda işe yarayacağını doğrulayabilirim, ancak performansı değil etkiyi değil.

Tüm veritabanını taşımak için bir yöntem BACKUPve RESTORE. Son anahtar sırasında veritabanı kullanılamayacak, ancak planlamada kesinti süresi en aza indirilmelidir. Bu yordam, FULLveya BULK_LOGGEDkurtarma modelini varsayar :

1) TAM yedekleme yapın (veya mevcut olanı kullanın).

2) En son tam yedeklemeyi farklı bir veritabanı adına geri yükleyin WITH MOVE, SSD depolama alanındaki dosyaları istendiği gibi yeniden konumlandırma NORECOVERYseçeneğini ve sonraki diferansiyel ve günlük yedeklemelerinin geri yüklenebilmesi seçeneğini belirtin.

3) İşlem günlüğü yedeklemeleri ve son kesime kadar yeni veritabanına artımlı değişiklikler uygulayın RESTORE...WITH NORECOVERY. Bu, yeni veritabanına son geçişin kesinti süresini en aza indirir.

4) Yeni veritabanına geçmek için uygulamayı çevrimdışına alın, son işlem günlüğü yedeklemesini gerçekleştirin ve yeni veritabanına uygulayın WITH RECOVERY. Son olarak, orijinal veritabanını farklı bir adla yeniden adlandırın ve taşınan veritabanını orijinal adıyla yeniden adlandırın. Eski veritabanını istediğiniz gibi bırakın.

BASİT kurtarma modelinde, benzer bir işlemi kullanabilirsiniz, ancak 3. adım işlem günlüğü yedeklemesi / geri yüklemesi olmadan. Bunun yerine, son adımda farklı bir veritabanı yedekleme / geri yükleme kullanın. İlk FULLyedeklemeden bu yana yapılan değişikliklerin miktarına bağlı olarak daha fazla aksama süresi gerekebilir .

Good approach is to use SQL REPLICATION between two server
once all data replicated on SSD server then take current server offline 
and switch to SSD server.