Perubahan skema SQL Server 2014 di lingkungan multi-pengguna 24/7

Kami memiliki SQL Server 2014 Enterprise diinstal untuk menjalankan database yang harus tersedia 24/7. Basis data kami cukup besar (200gb +). Kami juga memiliki banyak layanan yang mengenai basis data kami setiap menit untuk membaca, memperbarui atau memasukkan data baru. Kami ingin memberikan fitur penempatan kembali "panas" untuk klien kami dan menjadikan pembaruan harian kami (.net dan skema pembaruan) transparan kepada klien. Kami telah menemukan solusi berdasarkan pada cluster dengan load balancer untuk memperbarui binari aplikasi kami, tetapi kami masih memiliki beberapa kesalahpahaman tentang proses penyebaran basis data `update dan apa praktik terbaik untuk menyelesaikan masalah ini.

Untuk perubahan skema, turunkan satu server, terapkan perubahan skema, bawa kembali, dan kemudian terapkan perubahan yang sama ke instance kedua. Bisakah itu dilakukan dengan alat SQL Server, dan apakah ini pendekatan yang umum? Bagaimana sinkronisasi data setelah server dicadangkan? Atau apakah saya benar-benar berpikir ke arah yang salah dan apakah ada solusi yang lebih baik?

Perubahan Skema umum kami: menambah / menjatuhkan kolom, menambah / menghapus prosedur tersimpan

Di bawah ini akan memerlukan sedikit lebih banyak perencanaan dan pengujian.

Konsep Biru-Hijau:

Inti dari Konsep Biru-Hijau adalah untuk membagi produksi Anda menjadi 2 lingkungan dan mereka identik setiap saat (sinkronisasi data) di mana

1. Biru (Saat Ini) akan memiliki versi skema / build atau produk saat ini dan akan menjadi lingkungan "LIVE" Anda.

2. Pada saat yang sama Green akan menjadi lingkungan pementasan / pengujian di mana Anda akan memutakhirkan skema / bangunan atau produk Anda ke rilis NEXT, melakukan uji regresi penuh dan ditandatangani oleh pengguna bisnis Anda. Setelah bahagia, selama periode cut-over, Anda akan mempromosikan Green menjadi lingkungan "LIVE" Anda dan menurunkan Biru menjadi preprod / pementasan atau pengujian untuk rilis berikutnya.

Dengan cara ini, Anda memiliki waktu henti yang sangat sedikit dan risiko kegagalan penempatan pada sistem langsung (yang ada di jendela pemeliharaan, karena Anda melakukan peningkatan) akan sangat diminimalkan. Juga, mengikuti pendekatan Biru-Hijau, Anda akan berosilasi antara versi LIVE dan PREVIOUS yang akan menjadi pementasan untuk versi berikutnya.

Sekali lagi, ini akan membutuhkan lebih banyak perangkat keras / lisensi serta perencanaan dan pengujian.

Sebagian besar langkah dapat diotomatisasi menggunakan DACPAC dan PowerShell. Juga, jika Anda menginstal beberapa instance pada satu server, pastikan untuk menyeimbangkan kembali pengaturan Memori saat beralih antara Biru dan Hijau. Lingkungan LIVE mendapatkan lebih banyak memori daripada lingkungan Pasif.

Di lingkungan saya saat ini, kami telah menerapkan Model Biru / Hijau untuk Penerapan Kode Agile yang memungkinkan kami untuk mempromosikan kode setiap 2 minggu dengan jumlah waktu yang cukup untuk pengujian dan pengakhiran bisnis. Juga, mudah untuk mengembalikan jika terjadi kesalahan. Kami memiliki mayoritas penyebaran otomatis menggunakan Dacpac dan PowerShell.

(Sumber gambar)

Lihat juga artikel Grant Fritchey tentang Pemecahan Masalah Rollback dan Pemulihan; Tantangan dan Strategi

Jika database Anda tidak direplikasi, maka, tambahkan dan lepas kolom akan berjalan sangat cepat. Karena menambahkan kolom hanyalah posisi kosong yang dibuat SQL. Drop kolom hanya akan menghapus referensi.

Kalau tidak, jika ada kendala atau indeks pada itu hati-hati.

ADD/DELETEprosedur hanya akan berpengaruh pada eksekusi itu sendiri. Rekomendasi adalah sebelum ada perubahan di dalamnya menjalankan kompilasi ulang

sp_recompile 'myproc'