Mengelola Metadata Saat Membuat Database Tersedia di Server Lain

  • Artikel

Berlaku untuk:SQL Server

Artikel ini relevan dalam situasi berikut:

  • Mengonfigurasi replika ketersediaan grup ketersediaan AlwaysOn.

  • Menyiapkan pencerminan database untuk database.

  • Saat bersiap untuk mengubah peran antara server utama dan sekunder dalam konfigurasi pengiriman log.

  • Memulihkan database ke instans server lain.

  • Melampirkan salinan database pada instans server lain.

  • Melakukan peningkatan mesin database menggunakan metode - migrasikan ke penginstalan baru.

  • Memigrasikan database ke Azure SQL (Komputer Virtual atau Instans Terkelola).

Beberapa aplikasi bergantung pada informasi, entitas, dan/atau objek yang berada di luar cakupan database pengguna tunggal. Biasanya, aplikasi memiliki dependensi pada master database dan msdb , dan juga pada database pengguna. Apa pun yang disimpan di luar database pengguna yang diperlukan untuk fungsi database yang benar harus tersedia pada instans server tujuan. Misalnya, login untuk aplikasi disimpan sebagai metadata dalam master database, dan harus dibuat ulang di server tujuan. Jika rencana pemeliharaan aplikasi atau database bergantung pada pekerjaan SQL Server Agent, yang metadatanya disimpan dalam msdb database, Anda harus membuat ulang pekerjaan tersebut pada instans server tujuan. Demikian pula, metadata untuk pemicu tingkat server disimpan di master.

Saat Anda memindahkan database untuk aplikasi ke instans server lain, Anda harus membuat ulang semua metadata entitas dan objek dependen di dan mastermsdb pada instans server tujuan. Misalnya, jika aplikasi database menggunakan pemicu tingkat server, melampirkan atau memulihkan database pada sistem baru tidak cukup. Database tidak akan berfungsi seperti yang diharapkan kecuali Anda membuat ulang metadata secara manual untuk pemicu tersebut master dalam database.

Informasi, Entitas, dan Objek yang Disimpan di Luar Database Pengguna

Sisa artikel ini meringkas potensi masalah yang mungkin memengaruhi database yang tersedia di instans server lain. Anda mungkin harus membuat ulang satu atau beberapa jenis informasi, entitas, atau objek yang tercantum dalam daftar berikut. Untuk melihat ringkasan, pilih tautan untuk item tersebut.

Pengaturan Konfigurasi Server

SQL Server 2005 (9.x) dan versi yang lebih baru secara selektif menginstal dan memulai layanan dan fitur utama. Ini membantu mengurangi area permukaan sistem yang dapat diserang. Dalam konfigurasi default penginstalan baru, banyak fitur tidak diaktifkan. Jika database bergantung pada layanan atau fitur apa pun yang nonaktif secara default, layanan atau fitur ini harus diaktifkan pada instans server tujuan.

Untuk informasi selengkapnya tentang pengaturan ini dan mengaktifkan atau menonaktifkannya, lihat Opsi Konfigurasi Server (SQL Server).

Informasi Masuk

Kredensial adalah rekaman yang berisi informasi autentikasi yang diperlukan untuk menyambungkan ke sumber daya di luar SQL Server. Sebagian besar kredensial terdiri dari log masuk dan kata sandi Windows.

Untuk informasi selengkapnya tentang fitur ini, lihat Kredensial (Mesin Database).

Catatan

Akun Proksi Agen SQL Server menggunakan kredensial. Untuk mempelajari ID kredensial akun proksi, gunakan tabel sistem sysproxies .

Kueri Lintas Database

Opsi database DB_CHAINING dan TRUSTWORTHY NONAKTIF secara default. Jika salah satu dari ini diatur ke AKTIF untuk database asli, Anda mungkin harus mengaktifkannya pada database pada instans server tujuan. Untuk informasi selengkapnya, lihat MENGUBAH DATABASE (Transact-SQL).

Operasi lampirkan dan lepaskan menonaktifkan rantai kepemilikan lintas database untuk database. Untuk informasi tentang cara mengaktifkan penautan, lihat Opsi Konfigurasi Server rantai kepemilikan lintas db.

Untuk informasi selengkapnya, lihat juga Menyiapkan Database Cermin untuk Menggunakan Properti Tepercaya (Transact-SQL)

Kepemilikan Database

Ketika database dipulihkan di komputer lain, login SQL Server atau pengguna Windows yang memulai operasi pemulihan menjadi pemilik database baru secara otomatis. Saat database dipulihkan, administrator sistem atau pemilik database baru dapat mengubah kepemilikan database.

Kueri Terdistribusi dan Server Tertaut

Kueri terdistribusi dan server tertaut didukung untuk aplikasi OLE DB. Kueri terdistribusi mengakses data dari beberapa sumber data heterogen pada komputer yang sama atau berbeda. Konfigurasi server tertaut memungkinkan SQL Server menjalankan perintah terhadap sumber data OLE DB di server jarak jauh. Untuk informasi selengkapnya tentang fitur-fitur ini, lihat Server Tertaut (Mesin Database).

Data Terenkripsi

Jika database yang Anda sediakan pada instans server lain berisi data terenkripsi dan jika kunci master database dilindungi oleh kunci master layanan di server asli, mungkin perlu untuk membuat ulang enkripsi kunci master layanan. Kunci master database adalah kunci konten yang digunakan untuk melindungi kunci privat sertifikat dan kunci asimetris dalam database terenkripsi. Saat dibuat, kunci master database dienkripsi dengan menggunakan algoritma Triple DES dan kata sandi yang disediakan pengguna.

Untuk mengaktifkan dekripsi otomatis kunci master database pada instans server, salinan kunci ini dienkripsi dengan menggunakan kunci master layanan. Salinan terenkripsi ini disimpan di database dan di master. Biasanya, salinan yang disimpan di diperbarui secara diam-diam master setiap kali kunci master diubah. SQL Server pertama kali mencoba mendekripsi kunci master database dengan kunci master layanan instans. Jika dekripsi tersebut gagal, SQL Server mencari penyimpanan kredensial untuk kredensial kunci master yang memiliki GUID keluarga yang sama dengan database yang memerlukan kunci master. SQL Server kemudian mencoba mendekripsi kunci master database dengan setiap kredensial yang cocok sampai dekripsi berhasil atau tidak ada lagi kredensial. Kunci master yang tidak dienkripsi oleh kunci master layanan harus dibuka dengan menggunakan pernyataan OPEN MASTER KEY dan kata sandi.

Saat database terenkripsi disalin, dipulihkan, atau dilampirkan ke instans baru SQL Server, salinan kunci master database yang dienkripsi oleh kunci master layanan tidak disimpan di master instans server tujuan. Pada instans server tujuan, Anda harus membuka kunci master database. Untuk membuka kunci master, jalankan pernyataan berikut: OPEN MASTER KEY DECRYPTION BY PASSWORD ='password'. Kami menyarankan Agar Anda kemudian mengaktifkan dekripsi otomatis kunci master database dengan menjalankan pernyataan berikut: ALTER MASTER KEY ADD ENCRYPTION BY SERVICE MASTER KEY. Pernyataan ALTER MASTER KEY ini menyediakan instans server dengan salinan kunci master database yang dienkripsi dengan kunci master layanan. Untuk informasi selengkapnya, lihat OPEN MASTER KEY (Transact-SQL) dan ALTER MASTER KEY (Transact-SQL).

Untuk informasi tentang cara mengaktifkan dekripsi otomatis kunci master database database cermin, lihat Menyiapkan Database Cermin Terenkripsi.

Untuk informasi selengkapnya, lihat juga:

Pesan Kesalahan yang ditentukan pengguna

Pesan kesalahan yang ditentukan pengguna berada di tampilan katalog sys.messages . Tampilan katalog ini disimpan di master. Jika aplikasi database bergantung pada pesan kesalahan yang ditentukan pengguna dan database tersedia di instans server lain, gunakan sp_addmessage untuk menambahkan pesan yang ditentukan pengguna tersebut pada instans server tujuan.

Pemberitahuan Peristiwa dan Peristiwa Instrumentasi Manajemen Windows (WMI) (di Tingkat Server)

Pemberitahuan Peristiwa Tingkat Server

Pemberitahuan peristiwa tingkat server disimpan di msdb. Oleh karena itu, jika aplikasi database bergantung pada pemberitahuan peristiwa tingkat server, pemberitahuan peristiwa tersebut harus dibuat ulang pada instans server tujuan. Untuk melihat pemberitahuan peristiwa pada instans server, gunakan tampilan katalog sys.server_event_notifications . Untuk informasi selengkapnya, lihat Pemberitahuan Peristiwa.

Selain itu, pemberitahuan peristiwa dikirimkan dengan menggunakan Service Broker. Rute untuk pesan masuk tidak disertakan dalam database yang berisi layanan. Sebagai gantinya, rute eksplisit disimpan di msdb. Jika layanan Anda menggunakan rute eksplisit dalam msdb database untuk merutekan pesan masuk ke layanan, saat Anda melampirkan database dalam instans yang berbeda, Anda harus membuat ulang rute ini.

Peristiwa Instrumentasi Manajemen Windows (WMI)

Penyedia WMI untuk Peristiwa Server memungkinkan Anda menggunakan Instrumentasi Manajemen Windows (WMI) untuk memantau peristiwa di SQL Server. Aplikasi apa pun yang bergantung pada peristiwa tingkat server yang diekspos melalui penyedia WMI tempat database bergantung harus didefinisikan komputer instans server tujuan. Penyedia Acara WMI membuat pemberitahuan peristiwa dengan layanan target yang ditentukan dalam msdb.

Catatan

Untuk informasi selengkapnya, lihat Penyedia WMI untuk Konsep Peristiwa Server.

Untuk membuat pemberitahuan WMI menggunakan SQL Server Management Studio

Cara Kerja Pemberitahuan Peristiwa untuk Database Cermin

Pengiriman lintas database pemberitahuan peristiwa yang melibatkan database cermin bersifat jarak jauh, menurut definisi, karena database yang dicerminkan dapat gagal. Service Broker memberikan dukungan khusus untuk database cermin, dalam bentuk rute cermin. Rute cermin memiliki dua alamat: satu untuk instans server utama dan satu untuk instans server cermin.

Dengan menyiapkan rute cermin, Anda membuat perutean Service Broker mengetahui pencerminan database. Rute yang dicerminkan memungkinkan Service Broker untuk mengalihkan percakapan secara transparan ke instans server utama saat ini. Misalnya, pertimbangkan layanan, Service_A, yang dihosting oleh database cermin, Database_A. Asumsikan bahwa Anda memerlukan layanan lain, Service_B, yang dihosting oleh Database_B, untuk melakukan dialog dengan Service_A. Agar dialog ini memungkinkan, Database_B harus berisi rute cermin untuk Service_A. Selain itu, Database_A harus berisi rute transportasi TCP nonmirrored ke Service_B, yang, tidak seperti rute lokal, tetap valid setelah failover. Rute ini memungkinkan ACL untuk kembali setelah failover. Karena layanan pengirim selalu dinamai dengan cara yang sama, rute harus menentukan instans broker.

Persyaratan untuk rute cermin berlaku terlepas dari apakah layanan dalam database yang dicerminkan adalah layanan inisiator atau layanan target:

  • Jika layanan target berada di database cermin, layanan inisiator harus memiliki rute cermin kembali ke target. Namun, target dapat memiliki rute reguler kembali ke inisiator.

  • Jika layanan inisiator berada dalam database cermin, layanan target harus memiliki rute cermin kembali ke inisiator untuk memberikan pengakuan dan balasan. Namun, inisiator dapat memiliki rute reguler ke target.

Prosedur Tersimpan yang Diperluas

Penting

Fitur ini akan dihapus dalam versi SQL Server yang akan datang. Hindari menggunakan fitur ini dalam pekerjaan pengembangan baru, dan rencanakan untuk memodifikasi aplikasi yang saat ini menggunakan fitur ini. Gunakan Integrasi CLR sebagai gantinya.

Prosedur tersimpan yang diperluas diprogram dengan menggunakan SQL Server Extended Stored Procedure API. Anggota peran server tetap sysadmin dapat mendaftarkan prosedur tersimpan yang diperluas dengan instans SQL Server dan memberikan izin kepada pengguna untuk menjalankan prosedur. Prosedur tersimpan yang diperluas hanya dapat ditambahkan ke master database.

Prosedur tersimpan yang diperluas berjalan langsung di ruang alamat instans SQL Server, dan prosedur tersebut dapat menghasilkan kebocoran memori atau masalah lain yang mengurangi performa dan keandalan server. Anda harus mempertimbangkan untuk menyimpan prosedur tersimpan yang diperluas dalam instans SQL Server yang terpisah dari instans yang berisi data yang direferensikan. Anda juga harus mempertimbangkan untuk menggunakan kueri terdistribusi untuk mengakses database.

Penting

Sebelum menambahkan prosedur tersimpan yang diperluas ke server dan memberikan izin EXECUTE kepada pengguna lain, administrator sistem harus meninjau secara menyeluruh setiap prosedur tersimpan yang diperluas untuk memastikan bahwa prosedur tersebut tidak berisi kode berbahaya atau berbahaya.

Untuk informasi selengkapnya, lihat GRANT Object Permissions (Transact-SQL), DENY Object Permissions (Transact-SQL), dan REVOKE Object Permissions (Transact-SQL).

Mesin Teks Lengkap untuk Properti SQL Server

Properti diatur pada Mesin Teks Lengkap menurut sp_fulltext_service. Pastikan instans server tujuan memiliki pengaturan yang diperlukan untuk properti ini. Untuk informasi selengkapnya tentang properti ini, lihat FULLTEXTSERVICEPROPERTY (Transact-SQL).

Selain itu, jika komponen pemecah kata dan komponen stemmer atau komponen filter pencarian teks lengkap memiliki versi yang berbeda pada instans server asli dan tujuan, indeks teks lengkap dan kueri mungkin bereaksi berbeda. Selain itu, thesaurus disimpan dalam file khusus instans. Anda harus mentransfer salinan file tersebut ke lokasi yang setara pada instans server tujuan atau membuatnya kembali pada instans baru.

Catatan

Saat Anda melampirkan database SQL Server 2005 (9.x) yang berisi file katalog teks lengkap ke instans server SQL Server, file katalog dilampirkan dari lokasi sebelumnya bersama dengan file database lainnya, sama seperti di SQL Server 2005 (9.x). Untuk informasi selengkapnya, lihat Meningkatkan Pencarian Teks Lengkap.

Untuk informasi selengkapnya, lihat juga:

Pekerjaan

Jika database bergantung pada pekerjaan SQL Server Agent, Anda harus membuatnya kembali pada instans server tujuan. Pekerjaan bergantung pada lingkungannya. Jika Anda berencana untuk membuat ulang pekerjaan yang ada pada instans server tujuan, instans server tujuan mungkin harus dimodifikasi agar sesuai dengan lingkungan pekerjaan tersebut pada instans server asli. Faktor lingkungan berikut signifikan:

  • Login yang digunakan oleh pekerjaan

    Untuk membuat atau menjalankan pekerjaan SQL Server Agent, Anda harus terlebih dahulu menambahkan login SQL Server apa pun yang diperlukan oleh pekerjaan ke instans server tujuan. Untuk informasi selengkapnya, lihat Mengonfigurasi Pengguna untuk Membuat dan Mengelola Pekerjaan Agen SQL Server.

  • Akun startup layanan SQL Server Agent

    Akun startup layanan menentukan akun Microsoft Windows tempat SQL Server Agent berjalan dan izin jaringannya. SQL Server Agent berjalan sebagai akun pengguna tertentu. Konteks layanan Agen memengaruhi pengaturan untuk pekerjaan dan lingkungan eksekusinya. Akun harus memiliki akses ke sumber daya, seperti berbagi jaringan, yang diperlukan oleh pekerjaan. Untuk informasi tentang cara memilih dan mengubah akun startup layanan, lihat Memilih Akun untuk Layanan Agen SQL Server.

    Untuk beroperasi dengan benar, akun startup layanan harus dikonfigurasi agar memiliki izin domain, sistem file, dan registri yang benar. Selain itu, pekerjaan mungkin memerlukan sumber daya jaringan bersama yang harus dikonfigurasi untuk akun layanan. Untuk informasi, lihat Mengonfigurasi Akun dan Izin Layanan Windows.

  • Layanan SQL Server Agent, yang terkait dengan instans SQL Server tertentu, memiliki sarang registrinya sendiri, dan pekerjaannya biasanya memiliki dependensi pada satu atau beberapa pengaturan di sarang registri ini. Agar bereaksi seperti yang dimaksudkan, pekerjaan memerlukan pengaturan registri tersebut. Jika Anda menggunakan skrip untuk membuat ulang pekerjaan di layanan SQL Server Agent lain, registrinya mungkin tidak memiliki pengaturan yang benar untuk pekerjaan tersebut. Agar pekerjaan yang dibuat ulang bertingkah benar pada instans server tujuan, layanan SQL Server Agent asli dan tujuan harus memiliki pengaturan registri yang sama.

    Perhatian

    Mengubah pengaturan registri pada layanan SQL Server Agent tujuan untuk menangani pekerjaan yang dibuat ulang bisa bermasalah jika pengaturan saat ini diperlukan oleh pekerjaan lain. Selain itu, salah mengedit registri dapat sangat merusak sistem Anda. Sebelum Anda membuat perubahan pada registri, kami sarankan Anda mencadangkan data bernilai apa pun di komputer.

  • Proksi Agen SQL Server

    Proksi SQL Server Agent menentukan konteks keamanan untuk langkah pekerjaan tertentu. Agar pekerjaan berjalan pada instans server tujuan, semua proksi yang diperlukan harus dibuat ulang secara manual pada instans tersebut. Untuk informasi selengkapnya, lihat Membuat Proksi Agen SQL Server dan Memecahkan Masalah Pekerjaan Multiserver yang Menggunakan Proksi.

Untuk informasi selengkapnya, lihat juga:

Untuk melihat pekerjaan yang sudah ada dan propertinya

Untuk membuat pekerjaan

Praktik Terbaik untuk Menggunakan Skrip untuk Membuat Ulang Pekerjaan

Kami menyarankan agar Anda mulai dengan membuat skrip pekerjaan sederhana, membuat ulang pekerjaan di layanan SQL Server Agent lainnya, dan menjalankan pekerjaan untuk melihat apakah pekerjaan berfungsi seperti yang dimaksudkan. Ini akan memungkinkan Anda mengidentifikasi ketidakcocokan dan mencoba menyelesaikannya. Jika pekerjaan berskrip tidak berfungsi seperti yang dimaksudkan di lingkungan barunya, kami sarankan Anda membuat pekerjaan yang setara yang berfungsi dengan benar di lingkungan tersebut.

Masuk

Masuk ke instans SQL Server memerlukan login SQL Server yang valid. Login ini digunakan dalam proses autentikasi yang memverifikasi apakah prinsipal dapat terhubung ke instans SQL Server. Pengguna database yang login SQL Server terkait tidak ditentukan atau salah ditentukan pada instans server tidak dapat masuk ke instans. Pengguna seperti itu dikatakan sebagai pengguna tanpa intim dari database pada instans server tersebut. Pengguna database dapat menjadi yatim piatu jika setelah database dipulihkan, dilampirkan, atau disalin ke instans SQL Server yang berbeda.

Untuk menghasilkan skrip untuk beberapa atau semua objek dalam salinan asli database, Anda bisa menggunakan Wizard Hasilkan Skrip, dan dalam kotak dialog Pilih Opsi Skrip, atur opsi Masuk Skrip ke True.

Catatan

Untuk informasi tentang cara menyiapkan login untuk database cermin, lihat Menyiapkan Akun Masuk untuk Pencerminan Database atau Grup Ketersediaan AlwaysOn (SQL Server) dan Manajemen Login dan Pekerjaan Setelah Pengalihan Peran (SQL Server).

Izin

Jenis izin berikut mungkin terpengaruh ketika database tersedia di instans server lain.

  • IZIN GRANT, REVOKE, atau DENY pada objek sistem

  • IZIN GRANT, REVOKE, atau DENY pada instans server (izin tingkat server)

IZIN GRANT, REVOKE, dan DENY pada Objek Sistem

Izin pada objek sistem seperti prosedur tersimpan, prosedur tersimpan yang diperluas, fungsi, dan tampilan, disimpan dalam master database dan harus dikonfigurasi pada instans server tujuan.

Untuk menghasilkan skrip untuk beberapa atau semua objek dalam salinan asli database, Anda bisa menggunakan Wizard Buat Skrip, dan dalam kotak dialog Pilih Opsi Skrip, atur opsi Izin Tingkat Objek Skrip ke True.

Penting

Jika Anda masuk skrip, kata sandi tidak diskrip. Jika Anda memiliki login yang menggunakan Autentikasi SQL Server, Anda harus mengubah skrip di tujuan.

Objek sistem terlihat dalam tampilan katalog sys.system_objects . Izin pada objek sistem terlihat dalam tampilan katalog sys.database_permissions dalam master database. Untuk informasi tentang mengkueri tampilan katalog ini dan memberikan izin objek sistem, lihat IZIN Objek Sistem GRANT (Transact-SQL). Untuk informasi selengkapnya, lihat MENCABUT Izin Objek Sistem (Transact-SQL) dan Deny System Object Permissions (Transact-SQL).

IZIN GRANT, REVOKE, dan DENY pada Instans Server

Izin di cakupan server disimpan dalam master database dan harus dikonfigurasi pada instans server tujuan. Untuk informasi tentang izin server instans server, kueri tampilan katalog sys.server_permissions , untuk informasi tentang prinsipal server mengkueri tampilan katalog sys.server_principals , dan untuk informasi tentang keanggotaan peran server, kueri tampilan katalog sys.server_role_members .

Untuk informasi selengkapnya, lihat IZIN GRANT Server (Transact-SQL), IZIN SERVER REVOKE (Transact-SQL), dan Deny Server Permissions (Transact-SQL).

Izin Tingkat Server untuk Sertifikat atau Kunci Asimetris

Izin tingkat server tidak dapat diberikan langsung ke sertifikat atau kunci asimetris. Sebagai gantinya, izin tingkat server diberikan ke login yang dipetakan yang dibuat secara eksklusif untuk sertifikat atau kunci asimetris tertentu. Oleh karena itu, setiap sertifikat atau kunci asimetris yang memerlukan izin tingkat server, memerlukan login yang dipetakan sertifikatnya sendiri atau login yang dipetakan kunci asimetris. Untuk memberikan izin tingkat server untuk sertifikat atau kunci asimetris, berikan izin ke login yang dipetakan.

Catatan

Login yang dipetakan hanya digunakan untuk otorisasi kode yang ditandatangani dengan sertifikat atau kunci asimetris yang sesuai. Login yang dipetakan tidak dapat digunakan untuk autentikasi.

Login yang dipetakan dan izinnya keduanya berada di master. Jika sertifikat atau kunci asimetris berada dalam database selain master, Anda harus membuatnya master kembali dan memetakannya ke login. Jika Anda memindahkan, menyalin, atau memulihkan database ke instans server lain, Anda harus membuat ulang sertifikat atau kunci asimetrisnya dalam master database instans server tujuan, memetakan ke login, dan memberikan izin tingkat server yang diperlukan untuk masuk.

Untuk membuat sertifikat atau kunci asimetris

Untuk memetakan sertifikat atau kunci asimetris ke login

Untuk menetapkan izin ke login yang dipetakan

Untuk informasi selengkapnya tentang sertifikat dan kunci asimetris, lihat Hierarki Enkripsi.

Properti Terpercaya

Properti database TRUSTWORHTY digunakan untuk menunjukkan apakah instans SQL Server ini mempercayai database dan konten di dalamnya. Saat database dilampirkan, secara default dan untuk keamanan, opsi ini diatur ke NONAKTIF, meskipun opsi ini diatur ke AKTIF di server asli. Untuk informasi selengkapnya tentang properti ini, lihat properti database TRUSTWORTHY dan untuk informasi tentang mengaktifkan opsi ini, lihat MENGUBAH DATABASE (Transact-SQL).

Pengaturan replikasi

Jika Anda memulihkan cadangan database yang direplikasi ke server atau database lain, pengaturan replikasi tidak dapat dipertahankan. Dalam hal ini, Anda harus membuat ulang semua publikasi dan langganan setelah cadangan dipulihkan. Untuk mempermudah proses ini, buat skrip untuk pengaturan replikasi Anda saat ini dan, juga, untuk mengaktifkan dan menonaktifkan replikasi. Untuk membantu membuat ulang pengaturan replikasi Anda, salin skrip ini, dan ubah referensi nama server agar berfungsi untuk instans server tujuan.

Untuk informasi selengkapnya, lihat Mencadangkan dan Memulihkan Database yang Direplikasi, Pencerminan dan Replikasi Database (SQL Server), dan Pengiriman dan Replikasi Log (SQL Server).

Aplikasi Service Broker

Banyak aspek dari perpindahan aplikasi Service Broker dengan database. Namun, beberapa aspek aplikasi harus dibuat ulang atau dikonfigurasi ulang di lokasi baru. Secara default dan untuk keamanan, ketika database dilampirkan dari server lain, opsi untuk is_broker_enabled dan is_honoor_broker_priority_on diatur ke NONAKTIF. Untuk informasi tentang cara mengatur opsi ini AKTIF, lihat MENGUBAH DATABASE (Transact-SQL).

Prosedur Startup

Prosedur startup adalah prosedur tersimpan yang ditandai untuk eksekusi otomatis dan dijalankan setiap kali SQL Server dimulai. Jika database bergantung pada prosedur startup apa pun, database harus ditentukan pada instans server tujuan, dan dikonfigurasi untuk dijalankan secara otomatis saat startup.

Pemicu (di Tingkat Server)

DDL memicu prosedur tersimpan kebakaran sebagai respons terhadap beberapa peristiwa Bahasa Definisi Data (DDL). Peristiwa ini terutama sesuai dengan pernyataan Transact-SQL yang dimulai dengan kata kunci CREATE, ALTER, dan DROP. Prosedur tersimpan sistem tertentu yang melakukan operasi seperti DDL juga dapat mengaktifkan pemicu DDL.

Untuk informasi selengkapnya tentang fitur ini, lihat Pemicu DDL.

Lihat Juga

Database Terkandung
Menyalin Database ke Server Lain
Pencopotan dan Lampirkan Database (SQL Server)
FailOver ke Log Shipping Secondary (SQL Server)
Pengalihan Peran Selama Sesi Pencerminan Database (SQL Server)
Menyiapkan Database Cermin Terenkripsi
Pengelola Konfigurasi SQL Server
Memecahkan Masalah Pengguna Tanpa Infan (SQL Server)
Migrasi ke gambaran umum Migrasi penginstalanbaru: SQL Server ke SQL Server di Azure VM