¿Algún, Administrador de base de datos en SQL?
¿Que pueda contar que tal la experiencia en ese trabajo y algún consejo de por donde empezar y demás?
Tengo aprendido de SQL, lo poco que nos enseñaron en ASIR. ( Teníamos una profesora super pasota que nos enseño una mierda , select,from,where y hasta luego)
Actualmente están saliendo puestos en mi empresa que están bastante bien y me interesaría de cara al futuro.
Saludos
#1 DBA es ese tio que nadie sabe lo que hace y que cobra un pastón por ello... pero más te vale contratar a uno bueno.
Su trabajo realmente poco tiene que ver con selects (más bien con sentencias en general), sino que se encarga de mantener el servidor SQL.
Eso implica, no conocer SQL, sino conocer el funcionamiento interno del servidor (no es lo mismo un DBA de Orable SQL que de SQL Server por ejemplo).
Ha de controlar todo. Desde dimensionar bien la CPU y memoria asignadas, gestionar el espacio en disco (para BDs, para swap, etc), permisos, realizar tareas de mantenimiento sobre las BDs, etc...
Ahora bien, eso es un buen DBA... yo me he encontrado cada DBA que lo único que tenían era el cargo de DBA... y esos tienen el cargo de DBA pero ni los conocimientos ni el sueldo de un DBA.
Sobre mi experiencia he de decirte que es un trabajo muy desagradecido. Tu trabajo consiste en que todo vaya bien... si eres bueno y haces tu trabajo, el resto piensan que te estás tocando los huevos todo el día... de ahí que a menudo mi compañero y yo bromeáramos con "romper" algo xD
Dejando eso de lado, el trabajo es entretenido (como todo te ha de gustar), pero sí que es verdad que nos tocamos mucho los huevos xD (trabaja hoy para tocarte los huevos mañana y que nadie pueda quejarse de nada xD)
#2 Gracias por contestar.
Además he encontrado un antiguo compañero de ASIR, que actualmente trabaja de DBA Junior y me cuadra tanto lo que tu cuentas como lo que me cuenta el.
Así que a por ello.
¿Tienes o recomiendas alguna certificación en concreto?
Actualmente estoy estudiando por mi cuenta SQL y mirando cursos, en principio gratuitos.
Saludos
Semi DBA aqui (digo semi porque mi puesto implica mas cosas ademas de DBA), coincido en todo lo que indica #2. Sobre certificaciones, primero te recomiendo que mires en que tecnologia quieres trabajar y luego que te especialices en ello. No es lo mismo un DBA para Oracle que para MS SQL Server, SAP HANA, MongoDB, etc. o incluso para BBDD SQL o NoSQL. Le puedes echar un vistazo a las BBDD mas populares aqui:
https://db-engines.com/en/ranking
De esa lista no tocaria ni con un palo atado a un wifi Oracle. Las que me gustan por perspectivas de futuro y por como funcionan seria MS SQL Server, IBM DB2 (creo que va a ir para abajo en temas de popularidad y uso en el futuro), MS SQL Server / , MySQL/MariaDB, SAP HANA, MongoDB, Cassanda. Para temas de Big Data tienes Splunk, Hive y HBase.
Ojo que es un trabajo muy mal agradecido como dice #2, cuando todo va bien nadie se acuerda de ti pero cuando empiezan a ir mal las cosas todo el mundo se acordara de ti. Por ejemplo cuando el programador de turno desarrolle una puta mierda de query que tire la BBDD entera...
#4GaN2:el programador de turno desarrolle una puta mierda de query que tire la BBDD entera...
Ayer, dejamos al becario trastear con la BBDD en local y en 5 minutos la revento de arriba a abajo, i know that feel brah.
#5 Espero que no sea produccion... Porque me se de mas de un becario que ha reventado BBDD en productivos de una manera u otra.
Yo podria escribir un libro de anecdotas e historias de estos ultimos 10 años, la ultima hace un par de semanas con una BBDD que usamos como especie de DWH con datos de varias BBDD que se replican con diferentes tecnologias (SAP SLT, Oracle Golden Gate, etc), por encima lleva varias aplicaciones de reporting diferentes donde los usuarios tienen informes que desarrollan tanto ellos como los desarrolladores. Me llegan 2 incidentes P2 al movil de que la BBDD no estaba disponible, me meto y la veo al 100% de CPU. Estamos hablando de una BBDD in-memory con 72 cores y 8TB de RAM para que os hagais una idea asi que algo gordo estaba matando el rendimiento. Saco un dump de lo que esta corriendo y veo que la mayoria de threads se van en la ejecucion de un modelo de datos.
Mando correo a los responsables del modelo y me saltan que el modelo esta perfecto y que la culpa es del usuario. Hablo con el usuario que usaba el modelo desde la aplicacion de reporting para preguntar que ejecuta y me dice que ha ejecutado el modelo como viene para un informe, matamos la sesion y libera CPU. Le digo a los desarrolladores que miren el rendimiento y hagan pruebas en pre para ver que pasa con el modelo y su respuesta es ´si esto esta en produccion significa que funciona´, ´el usuario no tiene porque tener acceso al modelo padre, solo a los hijos´ o ´esto en PRE funcionaba perfectamente´. Luego te pones a rascar y ves que no hicieron pruebas en PRE porque pasa exactamente lo mismo o que se ´olvidaron´ de ocultar el modelo de datos a los usuarios en los roles...
Sobre otras historias, cual es la BBDD mas grande que administrais ahora mismo? Nosotros tenemos una in-memory con 480 cores y 20TB de memoria con replicacion y HA en dos nodos con los mismos recursos. Luego sin que sea in-memory tenemos otra que son unos 45TB de datos con un HA en Exadata con 8 nodos aunque esa no la administramos nosotros (tenemos equipo propio de Oracle) aunque nos toca lidiar cada vez que hay algun problema.
#7 Por necesidad, cuando empece en el mundo laboral mi perfil/puesto tenia que saber de todo (O/S, bases de datos, aplicativos, etc.) asi que no me quedo mas huevos que aprender. Por aquel entonces todos los sistemas SAP que administraba estaban en Oracle con Solaris asi que me toco aprender de ambos, luego metimos SAP ASE como nueva BBDD para algunos proyectos. Despues deje esa empresa y me meti en el mundo de la consultoria donde estuve currando los siguientes 5 años y donde tuve que aprender otros motores de BBDD: DB2, MS SQL Server, SAP ASE mas afondo, SAP HANA, MongoDB, etc. No me considero un experto en ninguno de ellos, si acaso en SAP HANA en mayor medida respecto del resto pero conozco como funcionan, su architectura, problemas de rendimiento que suelen tener, etc.
mm yo nunca he trabajado de esto pero con con un GBD lo único que haces es registrar datos y consultarlos no? me imagino que tendrá más funciones dicho puesto? o es su única función?
Yo trabaje con un DBA muy bueno y aparte de lo que ha dicho #2, añadiria dos softkills MUST:
Bueno me he sacado dos certificaciones, una de SQL y después otra de SQL Server 2019,... de las baratas , para linkedin y buscar como junior dba y entonces si sacarme las que valen 600euros o incluso mas.
Vosotros sobre el tema de certificaciones, tenéis alguna en especial o alguna que recomendéis?
céntrate en administración de sql, optimización, reporting, balanceo y clusters, etc... no te faltará trabajo.
Haz cursos, en la web de MS hay muchísima documentación. Si ya estás en la empresa, con un papel que diga que sabes SQL Server puede que te den el puesto. Después de eso, echale pelotas y pegate con todos los problemas que surjan y no te des por vencido. Aprendes a base de leches. Edit: #11 se me ocurre que pruebes con algo de Azure que es sencillo encontrar gratis a veces, algo tipo Fundamentals o orientado a data.
Animo y cuidado con producción que un día me marque un Robin Hood y metí durante 30min 0,5M de transacciones en una BBDD de producción de un banco no español, no sé hasta que punto afectó a las cuentas pero la cara de mi jefe un viernes a las 12 de la mañana no tiene precio. Como buen n00b que era en ese momento apunte todos los "ID" y pude sacarlos, nadie se quejó y cambiaron el acceso a producción (a mi se me cambió el esquema sin querer porque estaba migrando unas cosas de una bbdd de pruebas a otra nueva)
#12 Me has hecho reir cabron
#11 Intentaria sacarme alguna certificacion de Microsoft ya sea para SQL Server como tal o SQL Server en Azure. Como objetivo final puedes tirar hacia MSCA porque te da bastante pedigri, son 3 examenes los que tienes uqe sacar. En cualquier caso mas que certificacion lo mejor que puedes hacer es leer y aprender todo lo que puedas sobre la tecnologia que quieras trabajar, las certificaciones no dejan de ser un papel y muchas veces no reflejan lo bueno/malo que es una persona trabajando en ese campo.
Gracias a todos, espero que pronto este trabajando de dba y poniendo delete from sin ningún where y cosas asi. xD
Saludos
#17 DELETE es de parguelas, los hombres de verdad hacen DROP DATABASE en produccion sin backups. Recuerda, nunca seras un DBA de verdad hasta que no tengas que hacer un restore por alguna cagada que has hecho 
#18 Eso me sucedió a mi hace años, pensaba que estaba en Integración y me ventile un base de datos de 50GB en producción. Por suerte, aún no estaba abierta al público y en 30 minutos pude restaurar todo el dump.
#20 La ultima BBDD que alguien jodio fueron 12TB de restore (base de datos in-memory) y tardo en restaurar unas 18 horas, a alguien se le fue la mano con un rm a nivel de SSOO y borro los data files. Luego resulta que el backup de logs llevaba sin funcionar 30 dias y el ultimo full era de hace 15 dias, al final conseguimos restaurar sin perdida de datos de milagro. Lo bueno fue que era una BBDD del entorno de SPT que se estaba usando para las pruebas del ERP, todos los proyectos y golives impactados por la cagada, si llega a pasar en produccion esta mas de uno en la calle.
#22 Por suerte ninguno, pero ya me ves cargando los datos desde el portátil con una conexión de wifi de mierda, tuve mucha suerte que ese día no se nos cortó el internet
#23 Imagino que aparte de los full backups teníais los incrementales de cada día no? Porque sin logs veo jodido recuperarlo todo, y un buen pepino de server por tardar solo 18 horas
#24 Pues tuvimos la suerte de que los logs estaban en el file system, lo unico que Commvault no se los habia llevado al media agent y por lo tanto no los tenia en catalogo. Conseguimos lanzar el ultimo full que teniamos y luego hacerle el chanchullo a la BBDD para que usara los logs del file system hasta que restauro todo.
Sobre el server, tiene 20TB de RAM y 480 cores de CPU. Son dos nodos en cluster (dos nodos activo/pasivo con Dataguard):
Architecture: x86_64
CPU op-mode(s): 32-bit, 64-bit
Byte Order: Little Endian
CPU(s): 480
On-line CPU(s) list: 0-479
Thread(s) per core: 1
Core(s) per socket: 24
Socket(s): 20
total used free shared buff/cache available
Mem: 19527 14437 5074 7 15 5077
Swap: 3 0 3
Es una replica 1:1 de la misma BBDD que tenemos en produccion, a nivel de BBDD in-memory (SAP HANA) es el mas grande que tenemos pero luego hay otros que tienen SQL Server, Oracle, etc. que son mas grandes.
#26 Generalmente toda BBDD tiene diferentes tipos de backup:
Full / Incremental / Diferenciales: Como su nombre indican son backups completos o parciales de la base de datos. Diferenciales e incrementales son backups de los cambios que ha tenido la BBDD, generlamente para restaurar una BBDD necesitas un full + todos los incrementales o full + diferencial, la diferencia es que el diferencial siempre tiene todos los cambios desde el ultimo full y el incremental solo los cambios desde el ultimo backup (generalmente incremental).
Logs: Cuando una BBDD realiza una modificacion de un dato dicha modificacion generalmente pasa a un log area/transaction log area/log volumen dependiendo de la BBDD, posteriormente la BBDD sobreescribe dicha area segun se van realizando modificaciones o se pasan dichos datos a nivel de fichero que se guarda directamente en un directorio o en una almacenamiento externo ya sea mediante herramienta de backup o por unidad compartida/NFS/etc. Esto ocurre por varias razones, por ejemplo porque en caso de crash la BBDD tiene que tener una manera de volver a aplicar los cambios que estaban pendientes de aplicar en los data files (volumenes de datos), para mejorar rendimiento, etc.
Cuando quieres restaurar una BBDD a un punto en el tiempo determinado necesitas un Backup Full hasta dicho periodo y luego backup incrementales/diferenciales y backup de logs. O puedes restaurar un backup full + backup de logs. Dependiendo de la estrategia de backup/restore tardaras mas o menos en restaurar, generalmente se recomienda tener un full semanal, incrementales diarios y log backups cada X minutos, de esa manera puedes restaurar a un punto en el tiempo que quieras.
Si no tienes full estas jodido. Si no tienes incrementales pero tienes backup de logs te puedes salvar pero tardaras la vida en restaurar, si te falta un incremental y no tienes logs estas jodido.
Luego todo esto cambia dependiendo de la tecnologia de BBDD que uses, en Oracle por ejemplo los cambios se van escribiendo en los ficheros de redo log y segun van rotando se escriben en el destino que tengas configurado en archive red log. En SQL Server no es asi, los cambios se guardan en el transaction log y tienes que tener tu backup de logs para que se guarden posteriormente a archivo/backup y se libere el transaction log.
Lo bonito de las BBDD es que aunque generalmente todas hacen lo mismo (dentro de la diferencia entre SQL y nonSQL) luego a nivel interno cada una funciona diferentemente y todas tienen sus particularidades. Por ejemplo el no tener un indice creado en Oracle te puede matar el rendimiento mientras que a SAP HANA se la suda que tengas indice o no (no 100% cierto pero mas o menos ves por donde van los tiros).
#28 A menos que esten muy apurados de DBA en producción, pasaras la mayor parte del tiempo en PRE / Integracion / DEV preparando las cosas hasta que cojas soltura con el entorno y tengas claros los procedimientos.
).
