Caja de Herramientas (SQL Server)

Cuantas veces nos preguntamos... porque no conecta, porque si ya abrí el puerto x aun no funciona?, en muchas ocasiones las personas solo abren unos pocos puertos específicos, aquí voy a compartir dos archivos bats uno para versiones anteriores a 2008 y vista el otro para posteriores.

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.

Normalmente cuando realizamos una tarea por medio del SQL Server agent esta se ejecuta en el contexto de la cuenta de servicio del SQL Agent, excepto aquellos que son ejecuciones de código T-SQL.

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.

La tempdb es bastante importante para el buen funcionamiento de las base de datos, esta debe de tener algunas características que ya hemos tocado anteriormente en otro post . Basándose en estas recomendaciones el nuevo instalador de SQL Server ahora nos permite configurar en la instalación algunos de estos valores.

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.

Posiblemente el mantenimiento más importante para una base de datos en el día a día, es el mantener las estadísticas y los índices, esto nos afecta en varias maneras, la principal de todas es el desempeño que tienen nuestras consultas a la base de datos y que SQL Server pueda crear los planes de ejecución óptimos para cada consulta.

Las revisiones de integridad posiblemente sean la menos usada de las 3 principales partes del mantenimiento, cuando vemos su importancia normalmente es después de un desastre lo cual no es la mejor manera de aprender, pero en ocasiones necesaria. La integridad de datos que hablaremos aquí no est{a relacionada con la que se enfoca en que los datos entren de la manera esperada sino la consistencia de los archivos que contienen los datos.

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.

Bueno después de la salida oficial del SQL Server 2014 SP1 hace casi un mes y su retirada en menos de 24 horas volvemos a ver la liberación del SP1, normalmente no hablaría de algo así pero considero que existe un cambio muy importante que se debe de considerar en esta actualización.

Una de las herramientas menos utilizadas son los reportes internos que trae consigo SQL Server, los cuales son muy útiles para ver los backups, los vlf, espacio libre, uso de espacio por tablas, etc. Pero todos estos limitados a ver información dentro de una base de datos, pero que pasa si tenemos una situación a nivel instancia o de interacción entre las bases.

Como hemos visto un poco sobre memoria últimamente quería tocar un tema importante, que en la actualidad es de un uso cotidiano en las empresas y hasta para aquellos que quieren aprender, las máquinas virtuales, sean estas en VMWARE, Hyper-v, Red Hat, Citrix, etc.

Normalmente los errores de conexión son algo fácil de diagnosticar (no te estoy viendo NTLM), pero el día de hoy pase un par de horas con un bastante peculiar, todos conocemos los clásicos errores de conexión que aparecen en el Managment Studio cuando no podemos conectarnos, algo como:

El máximo grado de paralelismo, es como su nombre lo indica una medida que nos indica cuantos procesadores podemos usar, hoy en día es bastante común que un servidor (una pc o hasta una laptop) tenga varios procesadores físicos, SQL Server puede utilizar tantos como el servidor tenga y la licencia lo permita.

La tempdb es una de las 5 bases de sistema existentes (master, model, msdb, tempdb, resource), y la única que se puede beneficiar de ser configurada de manera distinta a como esta por defecto, aunque la model también esto sería un tema distinto , dependiendo de cada uno de nosotros y los ambientes que manejamos.

Es bastante normal que en sistemas locales la cuentas sean dejadas por defecto cuando creamos instancias de SQL Server, cuando creamos una cuenta de servicio de SQL Server en sus instalación esta obtiene varios permisos que sino son otorgados el servicio no podría levantar la instancia o esta funcionara de manera errática, pero que hacer si la queremos cambiar después de realizada la instalación.

Ú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 memoria para SQL Server es su recurso principal, debido a la manera en que SQL Server se maneja si no se establece un límite usara toda la memoria disponible, y esto puede causar presión de memoria en el sistema.

Como vimos en el anterior post, un índice es en comportamiento idéntico a un índice de un libro y nos sirve para poder realizar una busque más rápido y vimos los dos tipos de índices más comunes en SQL Server, ahora veremos a un nivel más técnico que es un índice.