Caja de Herramientas (SQL Server)

A petición de una persona se realizó un manual de como hacer un backup bajo la solución de SQL Server, intente hacerlo lo más simple posible y con links a la documentación en caso de que requieran ampliar la solución.

Esta pregunta es algo común en los foros y la respuesta es no, no es posible a menos que migres todos los objetos como scripts o algunas herramientas de vendedores pueden hacer esto de manera semi automática. Este post te dirá un poco el cómo detectar esto fuera de prueba y error.

En el primer post no se realizaron muchas acciones en tiempo real, la mayoría fue como detectar anticipadamente y un poco de cómo reaccionar a la misma pero supongamos ahora que tenemos una base en suspect, recovering, recovering pending o simplemente la gente se queja de lentitud y fallas pero ya rehicimos indices, estadísticas, revisamos los queries y nada solventa el problema.

Posiblemente uno de los mayores temores que tengamos siempre serán el hecho de que tengamos corrupción en una base o en varias de ellas, sino han tenido corrupción es bueno pero es altamente probable que tengas que enfrentarla en alguno momento en la vida, la corrupción puede ser instantánea o puede tener mucho tiempo en el sistema y hasta afectar las copias de seguridad.

Hace poco hablamos sobre los modelos de recuperación y siguiendo la temática de planes de mantenimiento que hemos llevado, me gustaría tomar un tiempo para ver lo que es la cadena de backups, que sino se cuida puede crear grandes problemas en especial si alguien hace un backup de manera no mal intencionada o cambia el modelo de recuperación para liberar el log de transacciones, para truncarlo y liberar espacio siguiendo ciertos consejos de la red.

Los modelos de recuperación son una parte muy importante de las bases de datos y relacionados a las copias de seguridad (backup), existen 3 tipos de modelos de recuperación, simple, full, bulk logged, esto impacta el espacio usado por los logs de transacciones y cuanto se puede recuperar en caso de recuperar información de una copia de seguridad.

Cuantas veces hemos escuchado de las copias de seguridad y su importancia, lamentablemente es una actividad que se le da poca importancia hasta que nos enfrentamos a un escenario de perdida de datos, de la misma manera es una actividad que parece fácil pero es más compleja que lo se puede apreciar inicialmente, una de las máximas de la recuperación de desastres es que tu plan sobre copias de seguridad es tan bueno como tu plan de recuperación, o sea realizar pruebas, no solo se queden con el conocimiento teórico.

Hace tiempo hablamos de los índices y estadísticas, pero no se comentó el punto de los planes de mantenimiento, un error de mi parte. Como casi todo en la vida las bases de datos se deterioran con el uso, para aminorar el impacto de esto debemos de dar un mantenimiento a las mismas, las 3 fases del mantenimiento preventivo se dividen en, revisión de integridad, mantenimiento de índices y estadísticas y toma de copias de seguridad.

Últimamente he visto varias situaciones de clientes, en espacial clientes que no tienen un DBA en sus empresa pero que usan otros productos como Dynamics, Lync y Sharepoint teniendo log de transacciones muy grandes (en un caso una base de 10GB con un log de transacciones de 863GB), y la pregunta de todos ellos es como recuperar ese espacio o reducirlo.

La corrupción de datos es algo con lo que ningún DBA se quiere encontrar en su vida profesional, lamentablemente es una posible ocurrencia, debido a que no es algo común es probable que  el DBA entre en pánico, lo primero en todo momento  es tener una copia de seguridad (Backup) de la información y conservar la calma.