El otro día me encontré con un artículo que vino a confirmar una sensación que tengo desde hace tiempo sobre el cometido de un DBA. Normalmente cuando se nombra el término “DBA”, se piensa en una persona que se encarga de analizar el rendimiento del servidor de base de datos con herramientas como el monitor de rendimiento, o consultando objetos de sistema (vistas, DMV, procedimientos almacenados, etc.). Tareas como replicación entre base de datos, log shipping, backups, creación de logins… son operaciones que sabemos que tiene que hacer esta persona.

En un entorno pequeño, esta persona se puede encargar además de “guiar” a los desarrolladores (o al jefe de proyecto) para que hagan las cosas del modo en que un experto en la materia (en este caso SQL Server) puede llegar a hacer. Sin embargo, en la mayoría de las empresas, el número de servidores hace que el trabajo del día a día impida realizar este otro tipo de operaciones, tanto o más importantes que las otras (incluso he conocidos algunos DBA que consideran estas tareas como degradantes). Esto supone en muchos casos que el DBA se termina encontrando con el problema directamente en el servidor de producción, ya que nadie ha validado que el proceso cumpla con unos requisitos de eficiencia mínimos: en unos casos porque el desarrollador no tiene los conocimientos suficientes (sí, sabe crear procedimientos almacenados, pero poco más) o el jefe de proyecto considera que lo principal de su trabajo consiste en que el modelo de clases que ha pensado quede bien reflejado, dando menor importancia a todo lo relacionado con la base de datos. En definitiva, por diversas circunstancias, el problema al final está ahí, y normalmente aparece en el peor momento.

Por eso hace tiempo empecé a pensar en que realmente deberían existir varios DBA o, mejor dicho, varios perfiles de DBA: uno de ellos se debería dedicar más a tareas relacionadas con los servidores de producción, encargándose de que ese entorno ofrezca el servicio que se presupone; pero otro de ellos debería encargarse de que las operaciones que se realizan en los entornos menos “conflictivos” cumplan con unos criterios de calidad mínimos, aconsejando en todo lo relacionado con el diseño de la base de datos (tablas, índices, funciones, procedimientos, etc.). De este modo el rendimiento vendría avalado por un experto en la materia, que tendría el mismo punto de vista que la persona que se encarga del entorno de producción, consiguiendo de ese modo, además, que los posibles problemas que puedan surgir se resuelvan mucho antes.

El artículo al que hacía referencia define muy bien el objetivo en el que deben centrarse estas dos figuras: el DBA (tal y como lo entendemos hasta ahora) debe centrarse en SQL Server como instancia, mientras que esta nueva figura debe centrarse en las bases de datos que alberga cada instancia de SQL Server.

¿Tú qué opinas? ¿Consideras que esta figura debería estar en todas las empresas? ¿Crees tal vez que el nivel de conocimientos de un desarrollador debe ser mayor en todo lo referente a las bases de datos? ¿Piensas que es el jefe de proyecto el que debe garantizar el rendimiento óptimo en base de datos?

0 Shares:
Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

You May Also Like
Leer más

Expresiones, parámetros y funciones en Azure Data Factory

Hay ocasiones, cuando estamos construyendo pipelines con Azure Data Factory, que queremos repetir patrones para extraer y procesar la información cambiando de manera dinámica, en tiempo de ejecución, valores, orígenes/destinos de los datasets, incluso los mismos linked services. Esto es posible mediante el uso de parámetros, expresiones y funciones. Vamos a ver cómo implementarlo con un ejemplo práctico en el que se nos plantea el siguiente supuesto. Se nos ha pedido que extraigamos todos los días los datos del día anterior de distintas tablas del DW a ficheros en un blob storage que además se nombre como la tabla de origen. Si no pudiéramos utilizar contenido dinámico tendríamos que crear dos datasets (uno de origen y otro de destino) y añadir una actividad de copia por cada tabla a exportar.

Nuevas funciones para el lenguaje de expresiones de SSIS en SQL 2012

El lenguaje de expresiones de Integration Services podemos utilizarlo en columnas derivadas, expresiones en propiedades de componentes, tareas, administradores de conexión, variables, en la nueva Expression Task, etc…  Tiene su propia sintaxis, operadores, conjuntos de funciones, etc.. (se observan similitudes con las expresiones de C++). En la versión de SQL 2012 se han agregado tres nuevas funciones que se engloban en el conjunto de funciones para el tratamiento de cadenas: Left, Token y TokenCount.
Leer más

Power BI embedded: Tus informes se vuelven omnipresentes

Crear reportes es esencial, pero, de nada sirve si no puedes compartirlos. Además de ver formas básicas de embeber un reporte de Power BI, esta sesión se centrará en cómo mostrar reportes dentro de sus propias aplicaciones web/móviles para compartir información con gente que está dentro y fuera de su organización (sin necesidad de cuenta de Power BI). Se trata brevemente Power BI Premium y Azure Power BI Embedded, así como otros temas relacionados con el licenciamiento.