Dalam artikel ini, kita akan meninjau kesalahan DBA, yang konsekuensinya cukup jelas dan harus saya tangani.
Tujuan artikel ini adalah untuk mencegah pengguna mengulangi kesalahan ini. Terkadang, pengalaman buruk bahkan lebih berharga daripada pengalaman positif.
- Peningkatan persentase file database
Karena pertumbuhan file dari database merupakan operasi yang memakan banyak sumber daya, tampaknya pengaturan rasio persentase pertumbuhan ini bisa menjadi ide yang bagus. Saya setuju bahwa banyak pedoman merekomendasikan pengaturan kenaikan tetap dalam MB, daripada persentase. Namun, mereka tidak menjelaskan alasannya. Berdasarkan praktik, tidak disarankan untuk mengatur kenaikan file database di atas 1 GB, karena MS SQL Server akan mengalokasikan 1 GB 2 kali daripada 2 GB sekaligus.
Juga, jika Anda mengalokasikan kurang dari 32 MB , cepat atau lambat database akan melambat. Jadi, lebih baik untuk mengatur kenaikan tetap pada file database dari 32 menjadi 1024 MB. Namun, mengapa tidak mungkin untuk menentukan peningkatan file database sebagai persentase? Ternyata begitu file kurang dari 1 MB, DBMS membulatkan nilai ini menjadi 0 MB dan berhenti menambah file ini. Akibatnya, sistem mati. Untuk mengetahui seberapa banyak kita perlu menambah file, cukup lakukan analisis harian untuk memeriksa berapa banyak setiap file bertambah dalam MB dan atur angka yang sesuai dalam kisaran 32 hingga 1024 MB. Kami dapat mengumpulkan statistik tentang pertumbuhan file database dengan cara berikut. - Ada banyak kunci asing untuk sebuah tabel
Pernahkah Anda mencoba memeriksa paket saat menghapus setidaknya satu baris dari tabel yang direferensikan oleh hampir ratusan tabel lainnya? Anda akan terkejut mengetahui berapa banyak loop bersarang yang ada. Semuanya adalah pemeriksaan kunci asing. Itu sebabnya jika tabel berukuran besar (lebih dari satu juta catatan), lebih baik menonaktifkan kunci asing untuk tabel yang datanya akan dihapus. Kemudian, Anda harus menghapus semua data yang diperlukan dan terkait. Setelah itu, aktifkan kunci asing. Situasi serupa terjadi dengan pembaruan dan penghapusan berjenjang. Jika ada banyak tautan eksternal (ratusan), menghapus satu baris saja dapat menyebabkan pemblokiran yang panjang dan sangat ekstensif. - Banyak indeks yang tidak perlu
Sangat sering, Anda dapat melihat dalam pedoman bahwa saat membuat kunci asing, perlu untuk membangun indeks, terutama saat menggunakan kunci ini untuk bergabung. Anda perlu memeriksa apakah indeks digunakan, jika tidak, indeks yang tidak perlu ini hanya akan memperlambat operasi modifikasi data apa pun. Untuk memeriksanya, gunakan kueri berikut:select DB_NAME(t.database_id) as [DBName] , SCHEMA_NAME(obj.schema_id) as [SchemaName] , OBJECT_NAME(t.object_id) as [ObjectName] , obj.Type as [ObjectType] , obj.Type_Desc as [ObjectTypeDesc] , ind.name as [IndexName] , ind.Type as IndexType , ind.Type_Desc as IndexTypeDesc , ind.Is_Unique as IndexIsUnique , ind.is_primary_key as IndexIsPK , ind.is_unique_constraint as IndexIsUniqueConstraint , t.[Database_ID] , t.[Object_ID] , t.[Index_ID] , t.Last_User_Seek , t.Last_User_Scan , t.Last_User_Lookup , t.Last_System_Seek , t.Last_System_Scan , t.Last_System_Lookup from sys.dm_db_index_usage_stats as t inner join sys.objects as obj on t.[object_id]=obj.[object_id] inner join sys.indexes as ind on t.[object_id]=ind.[object_id] and t.index_id=ind.index_id where (last_user_seek is null or last_user_seek <dateadd(year,-1,getdate())) and (last_user_scan is null or last_user_scan <dateadd(year,-1,getdate())) and (last_user_lookup is null or last_user_lookup <dateadd(year,-1,getdate())) and (last_system_seek is null or last_system_seek <dateadd(year,-1,getdate())) and (last_system_scan is null or last_system_scan <dateadd(year,-1,getdate())) and (last_system_lookup is null or last_system_lookup <dateadd(year,-1,getdate())) and t.database_id>4 and t.[object_id]>0 -- system databases are excluded
- Penggunaan sumber daya yang tidak efisien
Sering disarankan untuk menyimpan log transaksi dan file database pada perangkat penyimpanan yang berbeda. Jika Anda menggunakan RAID 10 dengan 4 dan lebih banyak SSD-disk, maka tidak ada gunanya mengisolasi file satu sama lain. Untuk kecepatan yang lebih tinggi, jika perlu, database tempdb dapat disimpan pada disk yang terpisah dari RAM. Selain itu, jumlah RAM yang terlalu besar yang disediakan untuk DBMS akan membuat DBMS mengisi semua memori dengan rencana kueri yang tidak relevan. - Cadangan buruk
Itu selalu diperlukan tidak hanya untuk memeriksa cadangan yang dibuat, tetapi juga untuk memindahkannya ke tempat uji dan memulihkannya. Semua ini perlu diotomatisasi dengan pemberitahuan lebih lanjut kepada administrator tentang pemulihan yang bermasalah dan berhasil. - Toleransi kegagalan yang buruk
Sebelum membuat cluster dua atau lebih server, Anda perlu memastikan bahwa sistem penyimpanan data juga tahan terhadap kegagalan. Jika yang terakhir gagal, seluruh toleransi kegagalan akan dikurangi menjadi nol. - Rumit diagnostik tanpa pemeriksaan sederhana
Jika ada sistem downtime, pertama, Anda perlu memeriksa log MS SQL Server dan kemudian menggali lebih dalam. Anda harus terlebih dahulu melakukan pemeriksaan sederhana dan kemudian melanjutkan ke diagnostik yang kompleks. - Tabel hilang
Tabel dapat diperpanjang dengan data yang tidak perlu yang perlu diarsipkan ke dalam database terpisah atau dihapus. Selain itu, tabel tidak dapat digunakan lagi.
Ini adalah situasi yang saya temui. Oleh karena itu, saya sarankan untuk tidak mengulangi kesalahan di atas.
Apakah Anda ingin berbagi pengalaman atau kesalahan semacam itu saat mengelola basis data, jangan ragu untuk memberi tahu saya – saya akan dengan senang hati mendiskusikannya.
