¿En qué áreas del conocimiento de un DBA debe profundizar un desarrollador? [cerrado]

Debo admitir que la pregunta es bastante amplia, así que intentaré reducirla un poco. En nuestra empresa somos 3-4 desarrolladores y tenemos algunas instalaciones basadas en SQL Server que se ejecutan en los sitios de nuestros clientes (tamaños de base de datos de hasta 100 GB, hasta 100 usuarios simultáneos, aplicaciones de intranet). Ninguno de nosotros tiene una experiencia realmente buena en la ejecución / mantenimiento / administración (lo que sea) de bases de datos. Los clientes ni siquiera tanto. Funciona bien hasta ahora, pero no puedo decir con certeza si es porque estamos haciendo todo bien o si simplemente no golpeamos áreas / situaciones en las que no somos competentes.

Por lo tanto, estoy buscando las cosas esenciales que necesita saber cuando ejecuta una base de datos desde el punto de vista de un DBA . Conoces los hechos concretos y sabes lo que más importa en tu trabajo diario.

¿En qué materias debo reunir un conocimiento más profundo, de qué debería haber escuchado y de qué no me puedo ocupar hasta que lo enfrente por primera vez?

Soy consciente de la pregunta Ingenieros de software y DBA , pero no es exactamente lo que estaba buscando. También hay muchos libros, pero me gustaría escucharlo de aquellos con experiencia práctica.

Me inclino a estar de acuerdo con @Catcall, la recuperación de la base de datos debería ser la primera de la lista. Las implicaciones tanto de las opciones de copia de seguridad como de recuperación son, por lo general, las que menos se comprenden fuera del equipo de DBA y las que tienen más probabilidades de provocar un desastre.

• Asegúrese de haber definido y acordado (por gestión técnica y no técnica) RPO (Objetivo de punto de recuperación) y RTO (Objetivo de tiempo de recuperación) para todas las bases de datos y sistemas.
• Documente los procedimientos de respaldo y recuperación en la medida en que puedan ser seguidos por personal no técnico.
• Asegúrese de que toda la documentación se mantenga impresa y electrónica, tanto dentro como fuera del sitio. Un runbook de recuperación ante desastres almacenado en la red local no será de mucha utilidad si los edificios se incendian.
• Pruebe todos los aspectos de los procedimientos de recuperación, a menudo. Las copias de seguridad son irrelevantes, lo que importa es la restauración.

A continuación, desde una perspectiva agnóstica de la base de datos, se comprende lo que un servidor de base de datos está diseñado para hacer; Proporcione atomicidad, consistencia, aislamiento y durabilidad a sus transacciones y datos. Comúnmente mal entendido, con frecuencia la causa de problemas de rendimiento y la principal fuente de inconsistencia de datos.

Para la plataforma elegida, entérese de cómo se implementa el cumplimiento de ACID. Busque temas como qué hace el registro de transacciones , qué es el registro de escritura anticipada , niveles de aislamiento y elementos internos de almacenamiento . Comprender los aspectos clave de los componentes internos de la base de datos hace que otros aspectos del trabajo DBA, el ajuste del rendimiento y la gestión de recursos, por ejemplo, sean mucho más fáciles de comprender.

Las dos cosas con las que trato todos los días.

1. Recuperación de desastres.

2. La optimización del rendimiento. (Tanto para consultas individuales como para el propio dbms).

Su plan de recuperación ante desastres debe ser

• guionizado
• probado, y
• experto.

Estoy usando una secuencia de comandos en el sentido de algo que seguiría un actor, no algo escrito en Python. Debería decirle a todos los que necesitan involucrarse exactamente qué hacer. (Y a menudo, exactamente qué decir también).

El ajuste del rendimiento para las consultas incluye la comprensión de claves, índices y normalización. (A menudo, los problemas de "ajuste" son en realidad problemas estructurales).