Kembali pada bulan Agustus 2015, saya menulis sebuah artikel yang memperkenalkan fitur baru Stretch Database di SQL Server 2016. Dalam artikel itu, saya membahas bagaimana memulai dengan Stretch Database di SQL Server 2016 Community Technology Preview 2 (CTP2). SQL Server 2016 dirilis pada 1 Juni 2016, dan ada banyak pembaruan pada produk. Metode pengaturan Stretch Database telah sedikit berubah serta beberapa fitur.
Dimulai dengan SQL Server 2016 kami memperoleh kemampuan untuk menyimpan bagian dari database di Azure SQL Database. Di pratinjau sebelumnya saat Anda mengaktifkan Peregangan untuk database, Anda harus memigrasikan seluruh tabel, dengan rilis RTM SQL Server 2016, Anda sekarang dapat memilih sebagian tabel. Setelah Anda mengaktifkan peregangan untuk tabel, itu akan memigrasikan data Anda secara diam-diam. Jika Anda tidak terbiasa dengan Stretch Database, ini memanfaatkan kekuatan pemrosesan di Azure untuk menjalankan kueri terhadap data jarak jauh dengan menulis ulang kueri. Anda tidak perlu menulis ulang pertanyaan apa pun di pihak Anda. Anda akan melihat ini sebagai operator "kueri jarak jauh" dalam rencana kueri.
Cara mudah untuk mengidentifikasi database dan tabel yang memenuhi syarat untuk mengaktifkan Stretch adalah dengan mengunduh dan menjalankan SQL Server 2016 Upgrade Advisor dan menjalankan Stretch Database Advisor. Aaron Bertrand (@AaronBertrand) menulis tentang ini beberapa waktu lalu. Penasihat Peningkatan telah sedikit berubah sejak posting Aaron, namun prosesnya sebagian besar sama:
- Identifikasi Tabel Kandidat untuk SQL Server 2016 Stretch Database
Batasan untuk Basis Data Peregangan
Tidak semua tabel memenuhi syarat untuk mengaktifkan Stretch. Properti tabel tertentu, tipe data dan kolom, batasan, dan indeks tidak didukung, seperti:
- Tabel dengan memori yang dioptimalkan dan direplikasi
- Tabel yang berisi data FILESTREAM, gunakan Ubah Pelacakan atau Ubah Pengambilan Data
- Tipe data seperti stempel waktu, sql_variant, XML, atau geografi
- Periksa atau batasan default
- Kendala kunci asing yang mereferensikan tabel
- indeks penyimpanan kolom XML, teks lengkap, spasial, atau berkerumun
- Tampilan terindeks yang mereferensikan tabel
- Anda tidak dapat menjalankan pernyataan UPDATE atau DELETE, atau menjalankan operasi CREATE INDEX atau ALTER INDEX pada tabel yang mendukung Peregangan
Untuk daftar lengkap batasan, Anda dapat mengunjungi:Persyaratan dan batasan untuk Stretch Database.
Menyiapkan Stretch Database
Memulai rilis RTM sedikit berbeda dari pratinjau sebelumnya. Anda memerlukan akun Azure, dan kemudian Anda harus mengaktifkan Stretch Database pada instance lokal.
Untuk mengaktifkan Stretch Database pada sebuah instance, jalankan:
EXEC sys.sp_configure N'remote data archive', '1'; RECONFIGURE; GO
Untuk demo ini saya akan menggunakan database sampel yang telah saya buat bernama STRETCH. Saya mulai dengan mengklik kanan pada database, memilih Tasks, Stretch, dan kemudian memilih Enable. Ini menggunakan SQL Server 2016 Management Studio.
Layar berikutnya menawarkan tabel mana yang ingin Anda aktifkan untuk Peregangan:
Saya memilih tabel SALES2. Wizard default ke "Seluruh Tabel", tetapi Anda juga dapat mengubah opsi itu untuk memigrasikan subset baris.
Jika Anda memilih berdasarkan baris, Anda harus memilih nama untuk kriteria Anda, lalu Anda dapat memilih kolom mana yang akan digunakan dalam pernyataan where Anda, serta kondisi dan nilainya. Dalam tangkapan layar ini saya memilih baris sebelum 2016. Mampu memilih sebagian tabel adalah peningkatan besar dibandingkan pratinjau sebelumnya, yang hanya memungkinkan Anda untuk meregangkan seluruh tabel. Untuk mempermudah, dalam demo ini, saya akan memigrasikan seluruh tabel, jadi saya mengklik Batal, lalu Berikutnya.
Setelah tabel dan ketentuan dipilih, Anda harus memilih langganan Azure yang akan digunakan, wilayah Azure, dan informasi server Anda.
Setelah Anda memasukkan informasi yang diperlukan, klik Berikutnya.
Peningkatan baru menggunakan kunci master database untuk melindungi kredensial Azure untuk menyambung ke Azure. Jika Anda belum memiliki kunci master, Anda akan diminta untuk membuatnya, jika Anda sudah memilikinya, Anda harus memberikan kata sandi. Klik Berikutnya.
Anda perlu membuat aturan firewall untuk server Anda, atau Anda dapat memasukkan rentang IP subnet. Tentukan pilihan Anda dan klik Berikutnya.
Di sinilah segalanya benar-benar berubah, dan akan membuat saya mempertimbangkan kembali untuk menggunakan fitur ini. Microsoft telah membuat Database Stretch Unit (DSU) sehingga Anda dapat meningkatkan atau menurunkan tingkat kinerja yang Anda perlukan untuk data Stretch. Mulai Juni 2016, harga saat ini ditagih untuk komputasi dan penyimpanan, yang Anda lihat ditunjukkan pada gambar di atas. Untuk tabel 15MB saya yang dimigrasikan, saya akan dikenakan biaya $61 USD per bulan untuk penyimpanan, serta tingkat DSU minimum (100) pada $912,50 per bulan. Level DSU berkisar dari:
| Tingkat DSU | Biaya per jam | Biaya bulanan maksimum (bulan dengan 31 hari) |
|---|---|---|
| 100 | $1,25 | $930 |
| 200 | $2,50 | $1,860 |
| 300 | $3,75 | $2,790 |
| 400 | $5.00 | $3.720 |
| 500 | $6,25 | $4.650 |
| 600 | $7,50 | $5,580 |
| 1000 | $12,50 | $9.300 |
| 1200 | $15.00 | $11.160 |
| 1500 | $18,75 | $13,950 |
| 2000 | $25.00 | $18.600 |
Mengapa wizard memberi tahu saya hanya $912,50, ketika lembar harga menunjukkan seharusnya $900 untuk bulan Juni (atau pro-rata berdasarkan berapa hari tersisa di bulan Juni)? Tebakan Anda sama bagusnya dengan tebakan saya; Saya sudah mencoba berbagai hal matematika dan tetap kosong. Anda dapat mempelajari lebih lanjut tentang model penetapan harga di sini:
- Harga Database Peregangan SQL Server
Sebelum mempelajari tentang metode penagihan baru untuk DSU ini, saya dapat berargumen bahwa menggunakan Stretch Database akan menjadi metode yang sangat hemat biaya untuk menyimpan data dingin (data yang tidak digunakan) ke dalam cloud. Dengan merentangkan data ini ke Azure, Anda dapat memigrasikan sebagian besar data lama, yang akan mengurangi ukuran (dan karenanya biaya) cadangan lokal Anda. Jika Anda harus memulihkan database, Anda hanya perlu membuat koneksi ke Azure untuk data yang diregangkan, sehingga menghilangkan kebutuhan untuk memulihkannya. Namun, dengan biaya minimal hampir $1.000 per bulan untuk skala DSU kelas bawah, banyak organisasi akan merasa jauh lebih murah untuk menyimpan data pada tingkat penyimpanan yang lebih murah di dalam pusat data mereka dan menemukan metode lain untuk HA seperti mirroring, pengiriman log, atau Grup Ketersediaan.
Klik Selesai untuk memulai migrasi.
Selamat, sekarang saya telah memigrasikan tabel SALES2 ke Azure SQL Database
Menonaktifkan tabel Peregangan
Di pratinjau awal Stretch Database, jika Anda ingin menonaktifkan tabel Stretch, Anda harus membuat tabel baru dan memasukkan data peregangan ke dalamnya. Setelah semua data disalin, maka Anda harus secara manual mengganti tabel dengan mengganti namanya, atau secara manual menggabungkan kembali data yang diregangkan ke dalam tabel produksi. Dengan rilis RTM, Anda masih dapat menangani migrasi secara manual, memilih untuk meninggalkan data di Azure, atau memilih opsi untuk mengembalikan data dari Azure.
Apa pun metode yang Anda gunakan untuk mengembalikan data, Anda akan dikenakan biaya transfer data.
Pencadangan dan Pemulihan Database Peregangan
Setelah Anda memigrasikan data ke dalam Stretch Database, Azure menangani pencadangan data Stretch. Pencadangan terjadi dengan snapshot yang diambil setiap 8 jam dan snapshot dipertahankan selama 7 hari. Ini memberi Anda hingga 21 poin waktu selama 7 hari sebelumnya untuk dipulihkan.
Anda tidak perlu membuat perubahan apa pun pada rutinitas pencadangan lokal Anda saat ini. Setiap pencadangan lokal yang diambil akan berisi semua data lokal dan data yang memenuhi syarat yang belum dimigrasikan. Ini disebut sebagai cadangan dangkal dan tidak berisi data apa pun yang telah dimigrasikan ke Azure.
DBCC CHECKDB
Anda juga tidak dapat menjalankan CHECKDB terhadap data yang telah dimigrasikan ke Azure.
Ketika saya menjalankan DBCC CHECKDB pada database STRETCH saya sebelum migrasi, saya mendapatkan hasil berikut untuk tabel SALES2:
Hasil DBCC untuk 'SALES2'.Ada 45860 baris dalam 1901 halaman untuk objek "SALES2".
Setelah migrasi, saya menerima output berikut untuk tabel SALES2 (penekanan milik saya):
Hasil DBCC untuk 'SALES2'.Ada 0 baris dalam 1901 halaman untuk objek "SALES2".
Anda dapat menjalankan DBCC CHECKDB terhadap Azure SQL Database, namun karena tidak dapat terhubung langsung ke Azure SQL Database yang direntangkan, saat ini Anda tidak dapat menjalankan DBCC CHECKDB secara manual terhadap data yang diregangkan secara khusus. Saya tidak dapat menemukan dokumentasi yang menyatakan Azure melakukan pemeriksaan konsistensi terhadap database ini.
Ini membawa risiko yang signifikan menurut saya.
Ringkasan
Stretch Database adalah cara mudah untuk memigrasikan data arsip ke Microsoft Azure, jika database Anda mendukungnya. Saat ini di SQL Server 2016 RTM terdapat banyak batasan dengan properti tabel, data, dan kolom, tipe data dan kolom, batasan, dan indeks. Jika Anda tidak dibatasi oleh batasan tersebut, maka Stretch Database adalah cara sederhana untuk memigrasikan data historis ke Azure SQL Database untuk mengosongkan penyimpanan lokal dan mengurangi waktu pemulihan database tersebut jika biaya membuatnya bermanfaat. Anda juga harus merasa nyaman, setidaknya untuk saat ini, dengan tidak dapat menjalankan DBCC CHECKDB terhadap data yang dimigrasikan. Mengelola pemulihan juga akan sedikit lebih rumit karena harus memulihkan koneksi antara database SQL Server dan database Azure jarak jauh.
