Sean, entiendo de dónde vienes.
Estamos en un barco similar aquí, como era de esperar, hay muchos otros. No soportando la economía actual.
A pesar de las reiteradas quejas a la gerencia, (incluida la alta gerencia de negocios), nuestra situación es esta; Desafortunadamente, el autodenominado "DBA" (en un "equipo de desarrollo" separado en otro piso) sabe menos que un joven que maneja dos libros O'Reilly y un volcado de impresión KB. Ella consiguió el trabajo, y es excelente para verter miel en el oído de la persona que también vierte miel en el oído del más sucio muckety-muck.
Seguramente, sería ideal poder aprender el "intercambio" de DBA, pero de nuevo ... Lo que queremos y lo que podemos tener a menudo son cosas muy diferentes. :)
Yo, personalmente, me he encontrado con los siguientes problemas, que (para hacerse eco de la experiencia de Squillman son bastante contundentes, pero no del todo incorrectos) requirieron mucho de googlear.
- Tranlogs. Tienes razón. ¿Qué demonios eran estas cosas? Así que tuvimos que restaurar una base de datos y un servidor, ¿qué significa exactamente 'reproducir los registros de tran'? :)
- Espera, ¿qué quieres decir con que estas bases de datos se vuelven más grandes? ¿Cómo los encogemos? O al menos mantener su crecimiento?
- Estandarización de instalaciones en diferentes servidores, (esta imagen es para "dev", esta imagen es para "prod" y esta pequeña imagen lloró todo el camino a casa, desde el mercado. :)
- Scripts de mantenimiento y cómo ayudar a administrar las bases de datos durante un largo período de tiempo (algo así como cultivar plantas de interior y asegurarse de que no se conviertan en kudzu).
- Siempre asegurándose de que los proggies van a C: \, el registro y / o las bases de datos van a D: \, que formuló nuestra estandarización, (C: \ son dos discos duplicados, D: \ suele ser un asunto RAID5 .)
- Tener que comprar una licencia SQL y un cliente por separado para las copias de seguridad.
- Eche un vistazo a la administración de usuarios que el equipo de desarrollo asigna a la base de datos SQL en sí misma, la administración de roles DBO, etc. Asegúrese de tener un buen modelo de seguridad en lo que respecta a los derechos de usuario dentro de la base de datos.
- Investigación de una cuenta de servicio de dominio con la que los servicios SQL pueden operar. Qué derechos necesita esa cuenta de servicio, si es que tiene alguno.
(Has tocado algunos muy buenos en tu publicación).
Dado que está operando en una desventaja como otras, asegúrese de difundir el conocimiento de SQL entre el equipo, si puede. Comparte lo que sabes, enseña a los demás lo mismo. Sé amable. Es un verdadero dolor tener que usar el sombrero SQL, pero al menos muchos ojos y procesos de pensamiento son mejores que uno solo.
Sin embargo, sobre todo, intenta como el demonio para obtener un DBA en el personal. :)