Memindahkan database SQL Server ke disk baru saat online

Saya memiliki 1.4TB SQL Server Database yang berjuang keras dengan disk I / O. Kami telah menginstal array SSD baru ke server yang akan menyelesaikan semua masalah kami, kami hanya memperdebatkan cara terbaik untuk memindahkan basis data. Idealnya jika kita bisa melakukannya tanpa downtime, itu yang terbaik. Tetapi di mana pilihannya adalah antara dua hari kinerja yang buruk (misalnya saat menyalin data) versus dua jam downtime, yang terakhir mungkin lebih disukai.

Sejauh ini, solusi yang kami buat adalah:

• Salinan sederhana. Bawa DB offline, salin file ke seberang, ubah lokasi di SQL Server dan bawa kembali online. Perkiraan angka kasar ini akan memakan waktu hingga lima jam, yang sebenarnya tidak dapat diterima, tetapi ini adalah solusi termudah.

• Salinan tingkat blok. Menggunakan utilitas mirip rsync, kami menyalin file di latar belakang saat DB naik. Ketika kami siap untuk bermigrasi, kami mengambil DB offline, melakukan salinan diferensial menggunakan utilitas ini, lalu arahkan SQL server pada file baru dan membawanya online. Pengaturan waktu di sini tidak diketahui. Kami tidak tahu berapa lama untuk melakukan analisis diferensial 1,4TB dan menyalinnya. Kekhawatiran kami yang lain adalah bahwa salinan level blok akan meninggalkan file dalam keadaan tidak terbaca oleh SQL Server dan kami akan membuang waktu kami.

• Migrasi SQL. Buat file data SQL 1.4TB baru pada disk baru dan nonaktifkan autogrowth pada semua file lainnya. Kemudian jalankan DBBC SHRINKFILE (-file_name-, EMPTYFILE) pada semua file data lainnya secara bergantian. Setelah semua data melintas, saya akan mengambil jendela terjadwal di beberapa titik untuk memindahkan file MDF ke SSD dan menghapus file yang tidak digunakan lainnya. Saya suka ini karena meminimalkan waktu henti. Tetapi saya tidak tahu berapa lama ini akan berlangsung dan apakah itu akan menyebabkan penurunan kinerja saat itu terjadi.

Kami tidak memiliki jenis beban & lingkungan kinerja untuk menguji ini. Saya dapat memverifikasi bahwa strategi akan bekerja pada lingkungan pementasan kami, tetapi tidak berdampak dan bukan kinerja.

Salah satu metode untuk memindahkan seluruh database adalah dengan BACKUPdan RESTORE. Basis data tidak akan tersedia selama saklar terakhir tetapi downtime harus minimal dengan perencanaan. Prosedur ini mengasumsikan FULLatau BULK_LOGGEDmodel pemulihan:

1) Lakukan cadangan FULL (atau gunakan yang sudah ada).

2) Kembalikan cadangan penuh terbaru ke nama database yang berbeda, tentukan WITH MOVEpilihan untuk memindahkan file pada penyimpanan SSD seperti yang diinginkan dan NORECOVERYopsi sehingga diferensial berikutnya dan cadangan log dapat dipulihkan.

3) Menerapkan perubahan inkremental ke database baru hingga saat final cut-over dengan cadangan log transaksi dan RESTORE...WITH NORECOVERY. Ini akan meminimalkan waktu henti untuk beralih ke database baru.

4) Untuk beralih ke database baru, buat aplikasi offline, lakukan backup log transaksi akhir, dan terapkan ke database baru WITH RECOVERY. Akhirnya, ganti nama database asli ke nama yang berbeda dan ganti nama database yang dipindahkan ke nama asli. Jatuhkan database lama sesuai keinginan Anda.

Dalam model pemulihan SEDERHANA, Anda bisa menggunakan proses serupa tetapi tanpa langkah 3 cadangan / pemulihan log transaksi. Sebagai gantinya, gunakan cadangan / pemulihan basis data diferensial di langkah terakhir. Itu mungkin memerlukan lebih banyak waktu henti, tergantung pada jumlah perubahan sejak FULLpencadangan awal .

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.