Trong bài viết này, chúng ta sẽ xem xét các sai lầm của DBA, hậu quả của chúng khá dễ nhận thấy và tôi phải giải quyết.
Mục đích của bài viết là để người dùng không lặp lại những sai lầm này. Đôi khi, trải nghiệm tồi tệ thậm chí còn có giá trị hơn trải nghiệm tích cực.
- Phần trăm tăng của tệp cơ sở dữ liệu
Vì tốc độ tăng tệp của cơ sở dữ liệu là một hoạt động khá tiêu tốn tài nguyên, nên có vẻ như việc thiết lập tốc độ tăng trưởng theo tỷ lệ phần trăm có thể là một ý tưởng hay. Tôi đồng ý rằng nhiều nguyên tắc khuyên bạn nên đặt mức tăng cố định bằng MB, thay vì phần trăm. Tuy nhiên, họ không giải thích lý do. Dựa trên thực tế, không nên đặt số gia của tệp cơ sở dữ liệu trên 1 GB, vì MS SQL Server sẽ phân bổ 1 GB 2 lần thay vì 2 GB cùng một lúc.
Ngoài ra, nếu bạn phân bổ dưới 32 MB , sớm hay muộn thì cơ sở dữ liệu sẽ chậm lại. Vì vậy, tốt hơn là đặt mức tăng cố định trên các tệp cơ sở dữ liệu từ 32 đến 1024 MB. Tuy nhiên, tại sao không thể chỉ định gia số của tệp cơ sở dữ liệu dưới dạng phần trăm? Nó chỉ ra rằng ngay khi tệp nhỏ hơn 1 MB, DBMS làm tròn giá trị này thành 0 MB và ngừng tăng tệp này. Kết quả là hệ thống bị trục trặc. Để biết chúng tôi cần tăng bao nhiêu tệp, chỉ cần thực hiện phân tích hàng ngày để kiểm tra xem mỗi tệp nhận được bao nhiêu MB và đặt số thích hợp trong phạm vi từ 32 đến 1024 MB. Chúng tôi có thể thu thập số liệu thống kê về sự phát triển của các tệp cơ sở dữ liệu theo cách sau. - Có nhiều khóa ngoại cho một bảng
Bạn đã bao giờ thử kiểm tra kế hoạch khi xóa ít nhất một hàng khỏi bảng được tham chiếu bởi gần hàng trăm bảng khác chưa? Bạn sẽ ngạc nhiên khi biết có bao nhiêu vòng lặp lồng nhau. Tất cả chúng đều là kiểm tra khóa nước ngoài. Đó là lý do tại sao nếu các bảng lớn (hơn một triệu bản ghi), tốt hơn nên tắt khóa ngoại cho bảng trong đó dữ liệu sẽ bị xóa. Sau đó, bạn sẽ cần phải xóa tất cả các dữ liệu cần thiết và liên quan. Sau đó, bật khóa ngoại. Tình huống tương tự cũng xảy ra với các cập nhật và xóa theo tầng. Nếu có nhiều liên kết bên ngoài (hàng trăm), thì việc xóa dù chỉ một hàng có thể dẫn đến việc bị chặn rất lâu và rất rộng. - Nhiều chỉ mục không cần thiết
Thông thường, bạn có thể thấy trong các hướng dẫn rằng khi tạo khóa ngoại, cần phải xây dựng các chỉ mục, đặc biệt là khi sử dụng các khóa này cho các phép nối. Bạn cần kiểm tra xem các chỉ mục đã được sử dụng chưa, nếu không, những chỉ mục không cần thiết này sẽ chỉ làm chậm bất kỳ hoạt động sửa đổi dữ liệu nào. Để kiểm tra điều này, hãy sử dụng truy vấn sau: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
- Sử dụng tài nguyên không hiệu quả
Bạn thường nên lưu trữ nhật ký giao dịch và tệp cơ sở dữ liệu trên các thiết bị lưu trữ khác nhau. Nếu bạn sử dụng RAID 10 với 4 ổ SSD trở lên, thì không có ý nghĩa gì khi cô lập các tệp với nhau. Để có tốc độ cao hơn, nếu cần, cơ sở dữ liệu tempdb có thể được lưu trữ trên đĩa được tách từ RAM. Ngoài ra, lượng RAM quá lớn được cung cấp cho DBMS sẽ khiến DBMS lấp đầy bộ nhớ với các kế hoạch truy vấn không liên quan. - Bản sao lưu không hợp lệ
Luôn luôn cần thiết không chỉ kiểm tra các bản sao lưu đã tạo mà còn phải di chuyển chúng trên giá thử và khôi phục chúng. Tất cả điều này cần được tự động hóa với thông báo thêm cho quản trị viên về các lần khôi phục có vấn đề và thành công. - Khả năng chịu lỗi kém
Trước khi tạo một cụm gồm hai hoặc nhiều máy chủ, bạn cần đảm bảo rằng hệ thống lưu trữ dữ liệu cũng có khả năng chịu lỗi. Nếu lỗi thứ hai không thành công, toàn bộ dung sai lỗi sẽ giảm xuống 0. - Phức tạp chẩn đoán mà không cần kiểm tra đơn giản
Nếu có thời gian ngừng hoạt động của hệ thống, trước tiên, bạn cần kiểm tra nhật ký MS SQL Server và sau đó tìm hiểu sâu hơn. Trước tiên, bạn nên tiến hành các kiểm tra đơn giản, sau đó tiến hành chẩn đoán phức tạp. - Bảng bị mất
Bảng có thể được mở rộng với dữ liệu không cần thiết cần được lưu trữ vào cơ sở dữ liệu riêng biệt hoặc bị xóa. Ngoài ra, các bảng này có thể không còn được sử dụng nữa.
Đây là những tình huống tôi đã gặp. Vì vậy, tôi khuyên bạn không nên lặp lại những sai lầm trên.
Bạn có muốn chia sẻ kinh nghiệm của mình hoặc những sai lầm như vậy khi quản lý cơ sở dữ liệu, vui lòng cho tôi biết - tôi rất vui được thảo luận.
