Pemeliharaan Database Sistem SQL Server

Instalasi SQL Server secara default membuat beberapa database sistem per instance untuk memelihara dan mengelola instance itu. Dalam artikel ini, kita akan memeriksa database sistem ini dan memahami tanggung jawabnya.

Database Sistem SQL Server

Di SQL Server, database sistem dibuat selama proses penginstalan untuk menyimpan detail konfigurasi khusus contoh SQL Server agar berfungsi secara normal. Setiap instalasi SQL Server membuat minimal 5 database sistem dan 1 database sistem terkait Replikasi bernama database distribusi yang akan dibuat oleh pengguna jika Replikasi dikonfigurasi dalam contoh itu. Setiap database Sistem memiliki tujuannya dan kami akan menyelidikinya secara mendetail nanti di artikel ini.

Basis data sistem adalah:

Master – Dipasang secara Default
Msdb – Diinstal secara Default
Model – Diinstal secara Default
Tempdb – Diinstal secara Default
Sumber Daya – Diinstal secara Default . Diperkenalkan di SQL Server 2005 dan tersedia di versi SQL Server yang lebih baru dan karenanya tidak tersedia di SQL Server 2000 dan versi sebelumnya.
Distribusi – Dibuat oleh Tindakan Pengguna . Pengguna dapat membuat database distribusi untuk mengonfigurasi Replikasi.

Untuk Melihat database sistem yang terinstal di SQL Server, kita dapat menggunakan SSMS.

Hubungkan ke instance SQL Server Anda, perluas Database > Database sistem :

Pernahkah Anda memperhatikan bahwa Sumber Daya database tidak ada dalam daftar di atas? Soalnya, resource database adalah database sistem khusus yang tidak terdaftar di SSMS Object Explorer. Namun, kami dapat menanyakan detail basis data sumber daya dari DMV sistem bernama sys.sysaltfiles dan jalankan kueri:

SELECT dbid, db_name(dbid) database_name, fileid, name, filename
FROM sys.sysaltfiles
WHERE dbid NOT BETWEEN 5 AND 11

Pada hasil, kita dapat melihat database sistem dalam urutan:master, tempdb, model, msdb, distribusi , dan, akhirnya, dbid 32767 yang merupakan basis data sumber daya. Namun, basis data sumber daya ini tidak menampilkan nama basis data apa pun karena tidak memiliki entri di sys.databases . Saya telah mengecualikan beberapa database pengguna antara dbid 5 dan 11 dan menyertakan AdventureWorks_REPL sebagai contoh untuk menunjukkan bahwa DMV juga dapat menampilkan database Pengguna. Kami akan membahas lebih detail tentang database Resource dan database sistem lainnya nanti.

Pembatasan Basis Data Sistem SQL

Karena database Sistem menyimpan detail konfigurasi sistem yang penting, harus ada langkah-langkah keamanan yang tepat untuk menghindari penghapusan data yang tidak disengaja. Oleh karena itu, database Sistem memiliki batasan di bawah ini dibandingkan dengan database pengguna:

Basis Data Sistem Tidak Dapat Dialihkan ke Offline

Kita dapat membuat database pengguna offline menggunakan perintah ALTER DATABASE seperti yang ditunjukkan di bawah ini:

ALTER DATABASE AdventureWorks SET OFFLINE WITH ROLLBACK IMMEDIATE
GO

Namun, jika kami mencoba untuk mengambil salah satu database sistem OFFLINE menggunakan perintah di atas, maka kami akan menerima kesalahan seperti yang ditunjukkan di bawah ini:

Basis Data Sistem Tidak Dapat Dijatuhkan

Sementara kita dapat menghapus database pengguna dengan menjalankan perintah DROP DATABASE

DROP DATABASE AdventureWorks

Jika kami mencoba DROP salah satu database sistem, maka kami akan menerima kesalahan seperti yang ditunjukkan di bawah ini:

Pemilik Basis Data Sistem Tidak Dapat Diubah

Pemilik database sistem adalah sa secara default. Itu tidak bisa diubah. Upaya untuk mengganti nama pemilik basis data Sistem akan memicu kesalahan.

Namun, ada pengecualian. Dimungkinkan untuk mengubah pemilik msdb basis data.

use [master];
GO
ALTER AUTHORIZATION ON DATABASE::[master] TO [RRJ\RRJ]
GO

Nama Basis Data Basis Data Sistem Tidak Dapat Diubah

Jika kita mencoba mengganti nama database sistem, maka kita akan mendapatkan pesan kesalahan seperti yang ditunjukkan di bawah ini:

ALTER DATABASE master MODIFY NAME = RRJ_master;
GO

Pengumpulan Basis Data Sistem Tidak Dapat Diubah

Database sistem dibuat dengan nama Collation yang dipilih selama penginstalan SQL Server. Setelah diinstal, Pengumpulan database sistem tidak dapat diubah. Satu-satunya cara untuk mengubah susunan database Sistem adalah menginstal ulang instance SQL Server dengan susunan yang benar.

Grup File Utama dari Basis Data Sistem Tidak Dapat Disetel ke Mode READ_ONLY

Karena database sistem menangkap informasi penting yang terkait dengan instans SQL Server, SQL Server tidak mengizinkan file data Primer yang berada di Grup File Utama untuk ditetapkan sebagai hanya-baca .

Fitur Ubah Pengambilan Data Tidak Dapat Diaktifkan di Basis Data Sistem

Fitur ini digunakan untuk melacak setiap perubahan DML yang terjadi pada database pada tabel yang dilacak. Jika kami mencoba mengaktifkan fitur Ubah Pengambilan Data pada basis data sistem apa pun, kesalahan akan terjadi:

use master
GO
exec sys.sp_cdc_enable_db

Sekarang kita sudah jelas tentang perbedaan antara database sistem dan database pengguna, kita dapat memeriksa tujuan dari setiap database sistem secara lebih rinci.

Basis Data Master di SQL Server

Basis data sistem Master menyimpan detail konfigurasi kunci yang terkait dengan instance SQL Server . SQL Server bergantung pada mereka ketika memulai contoh tertentu. Jika tidak mungkin untuk memulai database master karena alasan tertentu, instance SQL Server juga tidak dapat memulai.

Detail kunci yang disimpan dalam database master ini mencakup akun Login, detail Server Tertaut, titik akhir, pengaturan konfigurasi sistem, dan detail tentang semua database Pengguna.

Sekarang muncul pertanyaan. Bagaimana layanan SQL Server mengetahui di mana data dan file log dari database master tersedia? Jawabannya terletak pada parameter konfigurasi startup dari layanan SQL Server.

Untuk melihat parameter Konfigurasi Startup dari contoh SQL Server, pertama-tama kita harus mengetahui tentang alat bawaan bernama Pengelola Konfigurasi Server SQL . Ini membantu untuk mengelola semua layanan terkait SQL Server dari semua instance yang tersedia di Server tertentu. Untuk melihat data ini, buka SQL Server Configuration Manager dan akan menampilkan daftar seperti yang ditunjukkan di bawah ini:

Klik Layanan SQL Server untuk melihat daftar Layanan yang tersedia di Server atau PC ini:

Tunggu sebentar! Tampaknya familiar dengan services.msc daftar semua layanan yang tersedia di Server tetapi hanya menampilkan layanan terkait SQL Server.

Mari kita buka services.msc untuk melihat tampilannya dan memverifikasi perbedaan di SQL Server Configuration Manager dan services.msc untuk membandingkan mana yang lebih baik.

Manajer konfigurasi SQL Server menampilkan ID proses layanan yang sedang berjalan. Kami tidak dapat menemukannya di services.msc . Tentu saja, kami dapat memperoleh informasi ini dari Pengelola Tugas Windows, tetapi Pengelola Konfigurasi Server SQL membantu kami melihat ini di satu tempat.

Sekarang, mari kita lihat secara detail. Klik kanan pada layanan SQL Server dari services.msc . Anda akan melihat menu di bawah ini:Umum , Masuk , Pemulihan , dan Ketergantungan .

Dari Manajer Konfigurasi SQL Server, klik kanan pada SQL Server(MSSQLSERVER) layanan> Properti . Ini mencantumkan menu di bawah ini – Log On, Service. FileStream, Tingkat Lanjut, Ketersediaan Selalu Aktif , dan Parameter Startup .

Parameter Startup Layanan yang menyimpan lokasi data database master dan file log hanya tersedia di Manajer Konfigurasi SQL Server .

Klik Parameter Startup untuk melihat detail – untuk Yang Ada Parameter . Anda akan melihat info berikut:

Lokasi fisik database master File Data
Lokasi fisik database master File Log Transaksi
Lokasi fisik Folder Log Kesalahan di mana kesalahan yang terkait dengan SQL Server Service berada.

Kami dapat menambahkan lebih banyak parameter startup seperti Mode pengguna tunggal (-m) , dll. Untuk itu, kita perlu menentukan nilai yang diperlukan di Specify a Startup parameter dan klik Tambahkan .

Kami telah memperhatikan bahwa SQL Server Configuration Manager tidak hanya menampilkan detail lanjutan tetapi juga memungkinkan kami melakukan banyak konfigurasi lanjutan yang terkait dengan layanan SQL Server. Oleh karena itu, saya pribadi akan merekomendasikan menggunakan SQL Server Configuration Manager untuk Menghentikan/Memulai Layanan terkait SQL Server dibandingkan dengan opsi Services.msc default.

Praktik yang Direkomendasikan untuk Basis Data Master

Karena database master menyimpan detail penting tentang instans SQL Server, disarankan untuk mengikuti praktik terbaik saat menangani database tersebut.

Setiap perubahan konfigurasi pada instance SQL Server akan disimpan dalam database master. Oleh karena itu, Anda selalu perlu membuat cadangan penuh dari database master untuk memulihkan ke status terbaru jika kami memulihkan database master dari cadangan Penuh, sebagaimana diperlukan.

Meskipun SQL Server memungkinkan pengguna untuk membuat tabel pengguna atau objek lain di database master, tidak disarankan untuk melakukannya. Basis data master harus tetap sederhana dan bersih. Jika Anda perlu membuat objek pengguna di database master, Anda harus membuat Full Backup database master lebih sering.

SQL Server mendukung opsi prosedur Startup untuk menjalankan Prosedur Tersimpan tertentu saat memulai instance SQL Server. Ia menggunakan sp_procoption prosedur. Berhati-hatilah saat menggunakan opsi ini karena memiliki kode yang tidak optimal atau logika rekursif dapat memengaruhi waktu mulai instance SQL Server.

Jika SQL Server tidak dapat memulai karena masalah apa pun dengan database master, kami perlu memulihkan database master dari cadangan terakhir yang diketahui.

Model Basis Data di SQL Server

Seperti namanya, Database sistem model bertindak sebagai model atau template untuk setiap pembuatan basis data pengguna dalam hal jalur file, ukuran awal, setelan pertumbuhan otomatis, dan model Pemulihan, serta opsi konfigurasi lainnya .

Objek Pengguna apa pun seperti tabel, prosedur, dll., yang dibuat dalam database model juga akan dibuat secara otomatis di seluruh database pengguna baru dalam instance SQL Server tersebut.

Mari kita verifikasi ini dengan membuat tabel baru di database model:

Mari kita periksa apakah tabel ini ada di database model:

Basis data Model juga menyimpan Jalur File default dari basis data Pengguna seperti yang ditunjukkan di bawah ini di Properti Basis Data dari msdb basis data.

Sesuai konfigurasi saat ini, Ukuran File Awal dari keduanya Data dan File Log disetel ke 8 MB dengan pertumbuhan otomatis untuk keduanya disetel ke 64 MB.

Jika Anda perlu membuat database Pengguna di jalur file yang berbeda, bukan di lokasi file database model, kami dapat memodifikasinya di Properti Server dari Instance SQL Server tersebut.

Di SSMS, klik kanan pada Server > Properti > Setelan Basis Data . Lihat lokasi default Database:

Ubah jalur file ke jalur yang diinginkan dan klik OK . Basis data pengguna Data dan Masuk file akan dibuat di jalur baru yang Anda berikan.

Mari buat database baru bernama model_test dan periksa jalur file Data dan Log database baru bersama dengan properti file Initial dan Autogrowth dan model_verify tabel pada database baru.

Mari kita verifikasi model_test Jalur file Data dan Log. Klik kanan pada model_test database> Properti > File :

Seperti yang bisa kita lihat, Data dan Masuk file model_test database dibuat sesuai dengan jalur yang tersedia di database model. Nilai ukuran File Awal dari file Data dan Log adalah 8 MB. Nilai Autogrowth adalah 64 MB. Nilai-nilai ini cocok dengan konfigurasi database model.

Sekarang, kita akan memeriksa apakah model_verify tabel dibuat di model_test basis data. Kita bisa melihat database baru ini.

Selain tabel, ini berlaku untuk Tampilan, Prosedur Tersimpan, Fungsi, dan objek apa pun yang dibuat dalam database model.

Praktik yang Direkomendasikan untuk Model Database

Karena database model bertindak sebagai template untuk setiap pembuatan database pengguna baru, kita harus menerapkan praktik di bawah ini saat menanganinya:

Kapan pun Anda ingin menerapkan perubahan apa pun ke dalam konfigurasi basis data model (mis., Ukuran File Awal, Ukuran pertumbuhan otomatis, pembuatan objek pengguna, modifikasi, atau penghapusan), segera ambil Cadangan Penuh dari basis data model.

Karena setiap objek pengguna yang dibuat di database model dibuat di database pengguna mana pun, berhati-hatilah untuk menambahkan objek yang diperlukan saja. Jika tidak, banyak objek yang tidak perlu akan dibuat di semua database pengguna, dan Anda akan menghabiskan banyak waktu untuk menyortirnya dan membersihkan database Anda.

Konfigurasikan Ukuran File Awal dan parameter Pertumbuhan Otomatis untuk File Data dan Log. Ini membantu mengelola ukuran file Data dan Log di database pengguna dengan lebih baik dan meningkatkan kinerja.

Database MSDB

Basis data sistem msdb menyimpan informasi penting di bawah ini di seluruh tabel sistem:

Item terkait Agen Server SQL seperti Pekerjaan, Riwayat pekerjaan, Peringatan, Operator, Proksi, dll.
Fitur SQL Server seperti Service Broker dan Database Mail dengan konfigurasi dan detail riwayat.
Detail Pencadangan dan Pemulihan SQL Server disimpan di dalam tabel database msdb.
Konfigurasi Pengiriman Log, Profil Agen Replikasi, dan konfigurasi Pengumpul Data.
Paket pemeliharaan, Paket SSIS, dan beberapa detail lainnya.

Dengan kata lain, database sistem msdb menyimpan semua informasi penting yang terkait dengan Layanan Agen Server SQL dan beberapa layanan terkait lainnya.

Praktik yang Direkomendasikan untuk database msdb

Database msdb menyimpan banyak informasi konfigurasi penting yang terkait dengan SQL Server Agents, Jobs, dan Database Mail. Ini juga menyimpan detail sejarah. Oleh karena itu, kita harus menerapkan praktik di bawah ini saat menangani database msdb:

Dalam contoh SQL Server dengan banyak database atau Pekerjaan yang dikonfigurasi, ukuran database msdb akan meningkat terus menerus selama beberapa waktu. Oleh karena itu, Full Backups harus diterapkan untuk database msdb setiap hari bersama dengan database pengguna lainnya. Jika msdb menerima banyak informasi penting, maka kita dapat mengubah Model Pemulihan database msdb menjadi Penuh dan kemudian mengimplementasikan Backup Log Transaksi juga.

Meskipun SQL Server memungkinkan pengguna untuk membuat objek pengguna di database msdb, disarankan untuk tidak membuat tabel atau objek pengguna apa pun di database msdb dan memperbesar ukuran database msdb lebih lanjut.

Lakukan pembersihan rutin tabel sistem msdb untuk menjaga agar ukuran database msdb tetap terkendali dan menghindari dampak kinerja dari memiliki data besar di beberapa tabel.

Database Tempdb

Database sistem tempdb dapat dianggap sebagai area kerja global yang tersedia untuk semua pengguna yang terhubung ke instance SQL Server untuk melakukan SELECT atau operasi lainnya .

Basis data Tempdb akan menampung jenis objek di bawah ini saat pengguna melakukan operasinya:

Objek sementara yang dibuat secara eksplisit oleh pengguna dapat berupa tabel dan indeks sementara Lokal atau Global, Variabel Tabel, tabel yang digunakan dalam fungsi bernilai Tabel, dan Kursor.
Objek internal yang dibuat oleh mesin Database, seperti:
- Tabel kerja yang digunakan untuk hasil antara untuk gulungan, kursor, pengurutan, dan objek besar sementara (LOB)
- File kerja untuk operasi Hash Join atau Hash agregat
- Hasil sortir menengah saat menangani pembuatan atau pembuatan ulang indeks jika SORT_IN_TEMPDB disetel ke AKTIF dan operasi lain seperti kueri GROUP BY, ORDER BY, atau UNION
Toko Versi yang mendukung fitur pembuatan versi Baris, baik toko versi umum atau toko versi pembuatan indeks online.

Setiap kali layanan SQL Server dimulai atau dimulai ulang, database tempdb akan dibuat baru dengan bantuan database model. Dengan demikian, tempdb adalah satu-satunya database sistem yang tidak dapat dicadangkan .

Jika kami mencoba mencadangkannya, kami akan menerima kesalahan:

Karena kami menggunakan tempdb di hampir semua operasi pengguna, database ini menimbulkan hambatan kinerja yang signifikan di beberapa versi SQL Server. Mulai dari SQL Server 2016, ada beberapa teknik optimasi yang diterapkan oleh Microsoft – kita akan membahasnya nanti.

Sebelum masuk ke praktik yang direkomendasikan untuk database tempdb, mari kita lihat sekilas file datanya di bawah konfigurasi default seperti yang ditunjukkan di bawah ini:

Untuk Instance SQL Server saya saat ini, kami memiliki 4 file Data dan satu file Log untuk database tempdb.

Mulai dari SQL Server 2016, kami memiliki penginstal SQL Server yang memungkinkan kami untuk menambahkan banyak file ke tempdb. 4 file di atas dengan ukuran awal 8 MB dan ukuran Autogrowth 64 MB dibuat menggunakan opsi default yang ditunjukkan di bawah ini.

Jika kita memiliki satu file data dalam database tempdb, semua inti logis yang tersedia di server mencoba mengakses file data tempdb yang sama, yang mengakibatkan kemacetan kinerja.

Memiliki beberapa file data secara logis akan mengaitkan inti tertentu ke satu file. Dengan demikian, kami memiliki perselisihan yang lebih rendah pada file data tempdb. Ini akan meningkatkan dampak kinerja pada file data tempdb.

Praktik yang Direkomendasikan untuk Database tempdb

Karena database tempdb seperti area kerja global untuk semua aktivitas pengguna, ukuran tempdb meningkat berdasarkan aktivitas pengguna. Ini bisa menjadi hambatan kinerja untuk seluruh instance SQL Server.

Oleh karena itu, kita harus menerapkan praktik berikut:

Tempatkan file Data dan Log tempdb pada penyimpanan berkinerja tinggi untuk mendapatkan IOPS yang lebih tinggi untuk kinerja yang lebih baik.
Pastikan bahwa database tempdb dibagi menjadi beberapa file data untuk mengurangi pertentangan dan menghindari kemacetan kinerja pada database tempdb.
- Jika jumlah inti logis kurang dari 8, kita dapat memiliki satu file data tempdb per inti logis. Dalam contoh pengujian kami, kami memiliki 4 inti logis. Oleh karena itu, 4 file data di tempdb sudah cukup.
- Jika jumlah inti logis lebih dari 8, mulai dengan 8 file data dan tingkatkan sebanyak 4 file data jika masalah pertikaian dan kinerja diamati pada database tempdb.
- Jika jumlah inti logis di server adalah 32 atau 64, kita bisa mulai dengan 8 file data. Ini berarti bahwa 4 core atau 8 core terkait secara logis untuk satu file data.
  
  Untuk kejelasan lebih lanjut tentang beberapa file data tempdb, saya akan merekomendasikan Anda artikel luar biasa dari Paul Randal.
Pastikan bahwa file data tempdb dikonfigurasi dengan ukuran file awal yang optimal. Idealnya, ini harus dicapai melalui pendekatan coba-coba. Tempdb dengan ukuran file awal yang optimal cenderung tumbuh lebih sedikit kali dibandingkan dengan tempdb yang dikonfigurasi dengan ukuran file awal yang lebih kecil yang cenderung tumbuh beberapa kali yang mengarah ke fragmentasi. Misalnya, dalam konfigurasi saat ini, semua file dikonfigurasi dengan ukuran file awal 8 MB yang terlalu kecil untuk menangani Beban Kerja SQL. Jadi, terapkan pendekatan Trial and Error dan atur Ukuran File Awal ke 512 MB atau 1 GB, atau nilai lainnya.
Pastikan semua file data tempdb disetel ke ukuran file yang sama. Properti pertumbuhan otomatis harus didefinisikan sama. Dalam skenario kami, semua file diatur ke pertumbuhan otomatis 64 MB. Menyetel ukuran Pertumbuhan Otomatis ke 512 MB atau 1 GB, atau nilai lain yang sesuai membantu mengurangi pertumbuhan otomatis yang sering terjadi pada file data tempdb.
Pastikan bahwa ukuran File Awal dan Pertumbuhan Otomatis untuk file log tempdb dikonfigurasi ke nilai optimal yang serupa dengan file data tempdb. Karena model Pemulihan tempdb disetel ke Sederhana secara default dan tidak dapat dimodifikasi, mengonfigurasi ukuran file awal dan properti pertumbuhan otomatis dari file log tempdb sudah cukup.

Tempdb sangat penting untuk kinerja instans SQL Server. Kami akan melihat secara mendetail masalah yang sering dihadapi pada tempdb dan cara mengecilkannya secara optimal di artikel kami berikutnya.

Database Sumber Daya di SQL Server

Database Sistem Sumber Daya adalah satu-satunya database sistem hanya-baca yang tidak terdaftar di bawah database sistem di SSMS seperti yang terlihat sebelumnya.

ID Basis Data (dbid) database sumber daya di semua instans akan menjadi 32767 yang juga merupakan jumlah maksimum database yang didukung dalam instans SQL Server. Itu dapat ditanyakan dari sys.sysaltfiles sistem DMV. Menjalankan kueri SELECT di bawah ini pada sys.sysaltfiles akan mengembalikan hasil menunjukkan di mana file Data dan Log dari database sumber daya berada:

Kita dapat melihat file fisik dari database sumber daya yang tersedia di jalur yang disebutkan di atas. Tanggal yang diubah menunjukkan waktu penginstalan instans SQL Server atau terakhir kali Paket Layanan (SP) atau Pembaruan Kumulatif (CU) diterapkan pada instans ini.

Database Resource menampung semua objek sistem, seperti sys.objects , sys.databases , file sys.sysalt , dll. secara fisik di dalamnya. Database ini secara logis mencantumkan semua objek ini di bawah skema sys di semua database yang tersedia di instance . Karena database sumber daya bersifat hanya-baca, tidak ada objek atau data pengguna yang dapat dibuat di dalamnya.

Basis data sistem sumber daya diperkenalkan mulai dari SQL Server 2005 untuk membuat Peningkatan SQL Server ke versi baru SP atau CU lebih cepat. Sebelum memperkenalkan opsi itu, semua pemutakhiran dan pembaruan tersebut berarti bahwa perubahan akan berlaku di semua basis data, membuat proses pemutakhiran menjadi lebih rumit dan memakan waktu. Sekarang, setiap pemutakhiran versi SQL Server atau pemutakhiran SP atau CU hanya memutakhirkan atau mengganti basis data sumber daya.

Karena basis data sumber daya bersifat hanya-baca dan tidak terlihat oleh pengguna, maka tidak memerlukan intervensi pengguna apa pun. Jika Anda ingin menyertakan database sumber daya cadangan dalam perencanaan Ketersediaan Tinggi atau Pemulihan Bencana, cukup buat cadangan file dari file mssqlsystemresource.mdf dan mssqlsystemresource.ldf setelah menghentikan Layanan SQL Server (layanan SQL Server tidak akan mengizinkan untuk menyalin file saat Layanan SQL Server aktif dan berjalan) dan Simpan di lokasi yang aman. Berhati-hatilah untuk tidak memperbaruinya pada setiap contoh SQL Server yang berjalan dengan versi tingkat SP atau CU yang berbeda, karena dapat menyebabkan masalah yang tidak terduga.

Database Distribusi di SQL Server

Basis data sistem distribusi adalah jantung dari Replikasi. Pengguna dapat membuat atau mengkonfigurasi database distribusi sebagai bagian dari pengaturan Replikasi dengan bantuan baik Configure Distribution Wizard atau Create Publication Wizard. Kami menjelaskan langkah-langkah pembuatan database distribusi secara rinci sebagai bagian dari artikel saya sebelumnya tentang Internal Replikasi Transaksional SQL Server.

Praktik yang Direkomendasikan untuk Database Distribusi

Karena database distribusi sangat penting untuk fungsionalitas Replikasi, kita harus menerapkan praktik berikut:

Pindahkan database distribusi file Data dan Log ke drive dengan IOPS yang baik untuk menghindari masalah kinerja distribusi.

Konfigurasikan Ukuran File Awal dan properti Pertumbuhan Otomatis dari database distribusi ke nilai yang lebih baik untuk menghindari masalah fragmentasi.

Sertakan database distribusi ke Database Pekerjaan pemeliharaan cadangan lengkap.

Sertakan database distribusi ke tugas Pemeliharaan Indeks untuk menghindari fragmentasi dan masalah kinerja.

Dalam artikel saya tentang internal Replikasi Transaksional SQL Server, Anda juga akan menemukan rekomendasi tentang praktik efisien lainnya.

Kesimpulan

Terima kasih telah membaca artikel penuh daya lainnya!

Saya harap ini membantu Anda mengklarifikasi esensi dan tujuan database sistem SQL Server dan mempelajari praktik terbaik untuk menghindari masalah Performa pada database ini.