Nhà phát triển nên tìm hiểu về lĩnh vực kiến ​​thức nào của DBA? [đóng cửa]


11

Tôi phải thừa nhận câu hỏi khá rộng, vì vậy tôi sẽ thử thu hẹp nó lại một chút. Trong công ty của chúng tôi, chúng tôi có 3-4 nhà phát triển và có một số cài đặt dựa trên SQL Server đang chạy tại các trang web của khách hàng của chúng tôi (kích thước cơ sở dữ liệu lên tới 100GB, tối đa 100 người dùng đồng thời, các ứng dụng mạng nội bộ). Không ai trong chúng ta có kinh nghiệm thực sự tốt trong việc chạy / bảo trì / quản trị (bất cứ thứ gì). Các khách hàng thậm chí không nhiều. Cho đến bây giờ nó vẫn hoạt động tốt, nhưng tôi không thể chắc chắn liệu đó là vì chúng tôi làm mọi thứ đúng hay nếu chúng tôi không đánh vào những khu vực / tình huống mà chúng tôi không thành thạo.

Vì vậy, tôi đang tìm kiếm những điều thiết yếu bạn cần biết khi chạy cơ sở dữ liệu theo quan điểm của DBA . Bạn biết những sự thật khó khăn và biết những gì quan trọng nhất trong ngày của bạn cho công việc hàng ngày.

Trong những môn học nào tôi nên thu thập kiến ​​thức sâu hơn, tôi nên nghe về điều gì và tôi có thể quan tâm điều gì cho đến khi tôi đối mặt với nó lần đầu tiên?

Tôi biết câu hỏi về Kỹ sư phần mềm và DBA , nhưng nó không hoàn toàn là thứ tôi đang tìm kiếm. Cũng có rất nhiều sách xung quanh, nhưng tôi muốn nghe nó từ những người có kinh nghiệm thực tế.


Một số hiểu biết tốt có thể đạt được từ dba.stackexchange.com/questions/2905/ Khăn
Andrew Bickerton

Câu trả lời:


5

Tôi có khuynh hướng đồng ý với @Catcall, phục hồi cơ sở dữ liệu nên đứng đầu danh sách. Ý nghĩa của cả hai tùy chọn sao lưu và khôi phục thường được hiểu kém nhất bên ngoài nhóm DBA và có khả năng dẫn đến thảm họa cao nhất.

  • Đảm bảo bạn đã xác định và đồng ý (bằng quản lý kỹ thuật và phi kỹ thuật) RPO (Mục tiêu điểm khôi phục)RTO (Mục tiêu thời gian phục hồi) cho tất cả các cơ sở dữ liệu và hệ thống.
  • Các thủ tục sao lưu và phục hồi tài liệu đến mức có thể được theo dõi bởi các nhân viên phi kỹ thuật.
  • Đảm bảo tất cả các tài liệu được tổ chức ở dạng in cũng như dưới dạng điện tử, cả trên và ngoài cơ sở. Một cuốn sổ tay khắc phục thảm họa được lưu trữ trên mạng cục bộ sẽ không được sử dụng nhiều nếu các tòa nhà bốc cháy.
  • Kiểm tra mọi khía cạnh của thủ tục phục hồi, thường xuyên. Sao lưu là không liên quan, nó khôi phục vấn đề đó.

Tiếp theo, từ góc độ bất khả tri của cơ sở dữ liệu, là một sự hiểu biết về những gì một máy chủ cơ sở dữ liệu được xây dựng để làm gì; cung cấp tính nguyên tử, tính nhất quán, cách ly và độ bền cho các giao dịch và dữ liệu của bạn. Thường bị hiểu lầm, thường là nguyên nhân của các vấn đề hiệu suất và nguồn chính của sự không nhất quán dữ liệu.

Đối với nền tảng đã chọn của bạn, hãy tham gia vào phần bên trong về cách thực hiện tuân thủ ACID. Tìm kiếm các chủ đề như nhật ký giao dịch làm gì, ghi nhật ký trước là gì, mức cô lậpnội bộ lưu trữ . Hiểu các khía cạnh chính của nội bộ cơ sở dữ liệu làm cho các khía cạnh khác của DBA hoạt động, điều chỉnh hiệu suất và quản lý tài nguyên chẳng hạn, dễ nắm bắt hơn nhiều.


5

Hai điều tôi giải quyết mỗi ngày.

  1. Phục hồi thiên tai.

  2. Điều chỉnh hiệu suất. (Cả cho các truy vấn riêng lẻ và cho chính dbms.)

Kế hoạch khắc phục thảm họa của bạn cần phải được

  • kịch bản,
  • đã thử nghiệm, và
  • thực hành

Tôi đang sử dụng kịch bản theo nghĩa của một diễn viên sẽ làm theo, không phải là thứ được viết bằng Python. Nó nên nói với tất cả những người cần tham gia chính xác những gì cần làm. (Và thường, chính xác những gì cần nói, quá.)

Điều chỉnh hiệu năng cho các truy vấn bao gồm hiểu các khóa, chỉ mục và chuẩn hóa. (Thông thường các vấn đề "điều chỉnh" thực sự là các vấn đề về cấu trúc.)

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.