Caja de Herramientas (SQL Server)

Durante el 28/11/2015 en la ciudad de México en el campus San Rafael tuve la oportunidad de tener mi primera platica como speaker en un SQL Saturday, en la cual hable sobre desempeño y la herramienta gratuita de Microsoft Performance Dashboard Reports.

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.

Una de las nuevas características y posiblemente la más graciosa hasta la fecha es DIE (Drop If Exist) para SQL Server 2016, esta característica antes era usada por medio un IF con un resultado booleano que era evaluado pero ahora tenemos un código más legible.

El pasado 26 - 30 de Octubre se celebro el PASS Summit 2015 en Seattle, WA. Esta es la convención mas grande del año en lo que respecta a SQL Server, y donde participan grandes exponentes tanto internos de Microsoft como lideres del mercado.

Unas de las herramientas menos utilizadas son los reportes internos de SQL Server, estos reportes no son tan precisos en ocasiones con una DMV en tiempo en real pero son una herramienta de fácil uso que podemos usar, esta semana veremos unos reportes fáciles como los los de crecimiento de archivos

Hace poco un buen amigo me hizo notar que habría un SQL Saturday en México que buscaba expositores, ya sabia del evento al cual inscribí tiempo atrás, pero la invitación no fue para ir sino para participar como expositor, muchas veces en nuestra vida creemos que aun no estamos listos para varias situaciones pero en algún momento tenemos que salir de nuestra zona de conforte y atrevernos a algo nuevo, así que dije que si.

El PASS Summit 2015 es sin lugar a dudas el evento más grande que existe para un nerd, entusiasta de SQL Server y un evento importante sobre las bases de datos relacionales sin importar si hablamos de otros motores, mejoras sobre un motor deben impulsar a la competencia a ser mejor. El cual se llevara acabo del 26 al 30 de Octubre del 2015 en Seattle.

Hoy en día muchas cosas estan cambiando una de ella para nosotros que vivimos en el area de IT, es la computación en la nube, he visto muchas pregunta que hablan sobre accso a servidores sql fuera de la oficina, en oficinas remotas, geo replicación y hasta soluciones menos optimas como mover y copiar los data files, es entendible que la nube por ser algo "nuevo" nos asuste en especial por esa percepción de perdida de control.

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.

A penas el 27/07/2015 se libero lo que es el Windows 10, en una entrada anterior había visto la instalación de SQL Server 2014 sobre una versión beta, pero ya tenemos las versiones oficiales, debo de ser claro que un ambiente productivo nunca debe de estar sobre estas versiones sino sobre versiones Server como Windows Server 2012 R2 aun así les comparto lo que aprendi y encontre. (aparte del problema con GPO de Cortana).

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.

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.

El uso de alertas, es uno de los primeros pasos que debemos de tomar para poder alertarnos de problemas o alertas importantes sobre el estatus de la base de datos de manera pro-activa, aunque es posible llegar y en la mañana revisar el estado de nuestras instancias lamentablemente este método puede ser tardado y poco eficaz.

Hace aproximadamente unas dos semanas fue liberado el preview técnico de SQL Server 2016 CTP2, con bastantes novedades que ya platique anteriormente, por lo tanto me quise tomar la libertad de hacer un tutorial sobre la instalación de SQLServer en modo standalone.

Hace poco vi un error que nunca habiaa visto, mas bien porque nunca he tenido un problema con MDS. El cliente al intentar navegar el sitio del MDS se encontraba con un error "Unknown error", y este no se logeaba en ningún lado, event viewer, log de errores de SQL Server, etc.

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 cuestiones que debemos de tener presente siempre es donde buscar por esos pequeños dolores de cabeza que tenemos. Aquí solo cubriré lo que seria el motor y el agente pero tanto SSRS como SSAS manejan sus propios logs de errores.

Como se esta hacienda costumbre para Microsoft, tendremos un Nuevo sabor del popular manejador de base de datos para el siguiente año, esto fue mostrado en la semana en el Microsoft Ignite 2015, pero que ventajas o nuevas cosas nos trae esta versión contra las ya en el Mercado (recuerden que el aproximo año sale de soporte 2005).

Hace tiempo vi varios errores aunque en naturaleza distintos, tenían una intima relación. Esto era que el nombre del servidor donde estaba instalado SQL Server fue cambiado de nombre sin avisar al DBA (o de menos espero que así sea). La instancia aun inicia de manera normal, no tenemos problema al conectarnos o lanzar consultas.

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.

Esta semana recibí una petición algo rara de un cliente que un batch no se ejecutaba con un error 35330, el proceso involucraba una columnstore en SQL Server 2014 en lo cual debo de admitir que tengo poca experiencia y también he experimentado poco con ellos.

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:

Como se ha hablado en ocasiones anteriores, el recurso más importante para SQL Server es la memoria, en las versiones más nuevas ya todo es controlado por medio del Max Memory setting de SQL Server (bueno casi todo), en versiones 2008 R2 y anteriores esto solo administraba el buffer pool, aunque este es el que tiene el consumo más alto no es todo lo que controla por el Max Memory, ya que quedan fuera ciertos binarios y el CLR por citar unos ejemplos.

El Page life expectation es un valor que forma parte de los contadores de desempeño de la instancia de SQL Server, junto con otros variados que estan contenidos en la DMV sys.dm_os_performance_counters la cual encontraremos desde la versión de SQL Server 2005 aunque no con los mismos contadores en todas las versiones. Y nos sirve para medir la volatilidad de nuestro buffer pool (RAM).

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.

Como muchos he estado probando el Windows 10 Technical Preview, e instala tanto el Windows como el SQL Server sin muchos problemas, pero algunas personas en los foros no tuvieron tanta suerte, en especial con la version de español de Latino America de Windows 10 y la versión en español de SQL Server, aquí esta lo que he encontrado de momento.

En algunas ocasiones el motor de base de datos no logra levantar, la razón más común que he visto a sido una mala configuración realizada, en estos casos no levantar la instancia, por lo tanto es imposible entrar y modificar esta configuración.

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.

En los foros este fin de semana vi esta pregunta, y sinceramente me recordó cuando yo instale por primera vez el Sql Server 2014 y tampoco vi las data tools, para muchos talvez no signifique mucho en especial porque esto está más dirigido a lo que es BI o developers.