Tài nguyên cho DBA tình cờ [đã đóng]


16

Trong nền tảng của Microsoft, hầu hết các chương trình cấp doanh nghiệp (SharePoint, bất kỳ ứng dụng Trung tâm hệ thống, bất kỳ ứng dụng Dyamic nào, v.v.) đều chạy trên SQL Server. Đối với quản trị viên của các chương trình này, SQL Server thường là một hộp đen được cài đặt làm điều kiện tiên quyết cho bất kỳ chương trình nào là trọng tâm chính của họ. Kết quả là, có rất ít kế hoạch (nếu có) đi vào phía SQL của quá trình cài đặt, dẫn đến các vấn đề xuất hiện ở đâu đó ngược dòng.

  • Nhật ký giao dịch điền vào ổ đĩa
  • Không có kế hoạch bảo trì (hoặc kế hoạch không xác định, chẳng hạn như các kế hoạch vừa tổ chức lại và xây dựng lại các chỉ mục)
  • Tự động không quản lý
  • Cơ sở dữ liệu và nhật ký trên cùng một trục chính
  • Các cấp RAID được chọn kém
  • Không có bản sao lưu (hoặc gói phục hồi)

Vậy ... những loại vấn đề nào mà "các DBA tình cờ" có xu hướng gặp phải, và những tài nguyên nào sẽ giúp một DBA tình cờ đạt được tốc độ cơ bản về lập kế hoạch, quản trị và điều chỉnh hiệu suất SQL?

Câu trả lời:


10

Hãy xem loạt bài viết và các cột Hỏi & Đáp tôi viết cho Tạp chí TechNet - chúng chủ yếu được viết bằng DBA tình cờ (chúng tôi gọi đó là DBA 'không tự nguyện').

Lời khuyên hàng đầu để bảo trì cơ sở dữ liệu hiệu quả được viết cụ thể như là một mồi cho các DBA không tự nguyện để hiểu các vấn đề bảo trì DB.

Hiểu về ghi nhật ký và khôi phục trong SQL Server

Các vấn đề và giải pháp bảo mật máy chủ SQL phổ biến

Hiểu về sao lưu máy chủ SQL - phần 1 của loạt bài 3 phần. Phần 2 sẽ được sử dụng khôi phục (trong số phát hành ngày 09 tháng 9) và phần 3 sẽ được khôi phục mà không cần sao lưu (trong số phát hành ngày 09 tháng 11)

Bạn cũng nên kiểm tra blog của tôiblog của vợ tôi (không quảng cáo hoặc bất cứ thứ gì chỉ là thông tin) - cả hai chúng tôi đều viết blog một số lượng lớn trên nhiều cấp độ kỹ thuật.

Một loạt bài viết hay để xem qua là các bài xã luận về kết quả khảo sát hàng tuần của tôi . Chúng thường xoay quanh một chủ đề rộng có thể giúp các DBA không tự nguyện. Các bài đăng biên tập bắt đầu với 'Tầm quan trọng của' hoặc 'Quan trọng'. Trong thực tế cuộc khảo sát tuần này là về một DBA không tự nguyện - rất kịp thời!

Chúng tôi hiểu rất rõ điều DBA không tự nguyện - thực tế là Kimberly và tôi dạy một vài ngày cho lớp SharePoint Microsoft Certified Masters để quản trị viên SharePoint biết phải làm gì với Máy chủ SQL của họ (chúng tôi cũng dạy cả tuần về SQL SQL) .

Hy vọng điều này hữu ích cho bạn.


5

Sean, tôi hiểu bạn đến từ đâu.

Chúng tôi đang ở trong một chiếc thuyền tương tự ở đây, như tôi mong đợi là nhiều người khác. Không chịu được nền kinh tế ngày nay.

Mặc dù nhiều lần khiếu nại với quản lý, (bao gồm cả quản lý doanh nghiệp cao cấp), tình hình của chúng tôi là thế này; "DBA" tự bổ nhiệm (trong một nhóm 'phát triển' riêng biệt ở một tầng khác) không may biết ít hơn một thiếu niên đang cầm hai cuốn sách O'Reilly và một bản in KB. Cô ấy đã có được công việc, và thật tuyệt vời khi rót mật ong vào tai của người cũng đổ mật ong vào tai của muckety-muck higest-muck.

Chắc chắn, sẽ rất lý tưởng khi có thể học "giao dịch" DBA, nhưng một lần nữa .. Những gì chúng ta muốn và những gì chúng ta có thể có thường là những điều rất khác nhau. :)

Cá nhân tôi đã gặp phải những vấn đề sau đây, điều mà (để lặp lại tiếng nói của người bình thường khá cùn, nhưng không hoàn toàn không chính xác) đã đòi hỏi rất nhiều sự lo lắng.

  • Tranlogs. Bạn đúng. Những thứ này là cái quái gì vậy? Vì vậy, chúng tôi đã phải khôi phục cơ sở dữ liệu và máy chủ, chính xác thì 'phát lại các bản ghi tran' nghĩa là gì? :)
  • Đợi đã, ý bạn là gì khi những cơ sở dữ liệu này trở nên lớn hơn? Làm thế nào để chúng ta thu nhỏ chúng? Hoặc ít nhất là duy trì sự tăng trưởng của họ?
  • Tiêu chuẩn hóa cài đặt trên các máy chủ khác nhau, (hình ảnh này là dành cho "dev", hình ảnh này là dành cho "prod" và hình ảnh nhỏ này đã khóc trên đường về nhà, từ thị trường. :)
  • Các kịch bản bảo trì và cách giúp quản lý cơ sở dữ liệu trong một thời gian dài, (giống như trồng cây trong nhà và đảm bảo chúng không biến thành kudzu.)
  • Luôn đảm bảo, các proggies đi trên C: \, ghi nhật ký và / hoặc cơ sở dữ liệu đi trên D: \, loại công thức tiêu chuẩn hóa của chúng tôi, (C: \ là hai đĩa được nhân đôi, D: \ thường là một vụ RAID5 .)
  • Phải mua một giấy phép SQL và máy khách riêng biệt để sao lưu.
  • Kiểm tra việc quản lý người dùng mà nhóm phát triển gán cho chính cơ sở dữ liệu SQL, quản lý các vai trò DBO, v.v ... Đảm bảo bạn đã có một mô hình bảo mật tốt khi nói đến quyền người dùng trong cơ sở dữ liệu.
  • Nghiên cứu một tài khoản dịch vụ miền mà các dịch vụ SQL có thể hoạt động như. Những quyền mà tài khoản dịch vụ cần, nếu có.

(Bạn đã đạt được một số khá tốt, trong bài viết của bạn.)

Vì bạn đang hoạt động ở một điểm chấp như một số người khác, hãy đảm bảo bạn truyền bá kiến ​​thức SQL trong nhóm, nếu bạn có thể. Chia sẻ những gì bạn biết, dạy người khác như vậy. Thân thiện. Đó là một nỗi đau thực sự khi phải đội mũ SQL, nhưng ít nhất nhiều quá trình suy nghĩ và mắt tốt hơn một lần duy nhất.

Tuy nhiên, trên hết, hãy cố gắng như quỷ để có được một nhân viên DBA. :)


2

Tôi đã nhận được danh hiệu anh chàng DBA khoảng một năm trong công việc của tôi. Đây là khoảng 5 tháng trước. Kể từ đó, tôi đã đọc nhiều blog khác nhau từ chế độ xem 500.000 ft đến (đôi khi nhấn vào sàn cứng ở chế độ 500.000) 250.000 , đến chế độ xem 500 ft . Ngoài ra, SQLServerPedia là bạn của bạn; họ có rất nhiều thứ tốt cho DBA tình cờ.

Tôi đã bị ném vào những tình huống khiến tôi cảm thấy khó chịu. Ví dụ, tôi đã thực hiện sao lưu kể từ khi tôi nhận được công việc này vì vậy Fulls, diffs và t-log đã có trong tay để khôi phục dữ liệu sản xuất đầu tiên của tôi, không ai khác có vẻ hoảng loạn, vì vậy tôi nghĩ rằng tôi không thể hiển thị tôi cảm thấy buồn nôn làm sao Nhiều lần hơn không, tôi quá nhiệt tình khi đội chiếc mũ DBA của mình, nhưng tôi nghĩ đó không phải là công việc toàn thời gian của tôi (quản trị viên mạng) vì vậy tôi nên 'an toàn hơn là xin lỗi'.


SQLServerPedia thực sự là một tài nguyên tuyệt vời! Cảm ơn đã chỉ ra rằng.
marc_s


0

Bắt đầu với những nỗ lực chiến thuật. Nếu cơ sở dữ liệu của bạn bị sập hoặc không hoạt động tốt, hãy tập trung giải quyết những vấn đề đó.

Tiếp theo bắt đầu với các mục chiến lược hơn: sao lưu và khôi phục. Biết cách khôi phục cơ sở dữ liệu của bạn từ trong ra ngoài và tạo các quy trình chi tiết để ngăn ngừa các lỗi tốn kém trong thời gian ngừng sản xuất.

Nếu bạn không có phần cứng để kiểm tra các thay đổi lớn và những thứ như sao lưu / khôi phục - hãy tìm ra cách để có được nó.


0

Khi tôi thuê Junior DBA, tôi đã mua cho cô ấy Trình quản trị viên Microsoft® SQL Server (TM) 2005. Đó là cuốn sách tôi ước tôi có khi tôi bắt đầu.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.