SQL Server

Creando y manteniendo índices FullText

Continuamos con el tema de ayer sobre los índices de texto completo y hoy vamos a centrarnos en aspectos más prácticos. Si aún no has leído el artículo introductorio de ayer sobre los índices FullText te recomiendo que lo hagas antes de seguir con este para saber de lo que estamos hablando. Si ya leíste vamos a hacer un pequeño resumen para reforzar los conceptos clave. Los índices de texto completo o FullText son unos índices especiales que nos ayudarán en nuestras búsquedas sobre columnas con gran cantidad de texto. Además, tienen la particularidad de que se organizan en catálogos, aspecto clave para su creación y futuro mantenimiento.

Requisitos para crear un índice FullText

Para crear los índices FullText lo primero que necesitaremos será tener instalada la característica de SQL con la que trabajan, no tiene pérdida se llama FullText o Texto Completo dependiendo del idioma de nuestro instalador. Una vez instalada tenemos que asegurarnos de tener corriendo el servicio para la extracción de texto completo, tampoco tiene pérdida y lo localizaremos por su nombre rápidamente junto con el resto de servicios en el administrador de configuración de SQL Server. 

Una vez estemos seguros de que el servicio está instalado y en ejecución podremos proceder con la creación del catálogo que, recordad que es requisito imprescindible para este tipo de índices. Para crear el catálogo usaremos la sintaxis siguiente sintaxis: 

Para ver los catálogos existentes podemos hacerlo en SSMS, desplegando la carpeta almacenamiento dentro de la base de datos o con la siguiente consulta:

FullText_Catalog

Creación de índices FullText

Una vez que cumplamos con los requisitos anteriores estaremos ya preparados para crear nuestro índice FullText. Tenemos que saber que podemos crear índices de texto completo tanto en tablas como en vistas indexadas pero solo uno por tabla (o vista). El índice de cada tabla podrá contener hasta 1024 columnas. La sintaxis de creación es la siguiente:

No voy a entrar en todas las opciones de creación de un índice FullText, para eso podéis consultar la documentación oficial aquí. Nos vamos a centrar en las más importantes. Como veis es parecido a la sintaxis de creación de índices que todos conocemos. Especificaremos la tabla sobre la que crearlo y las columnas que incluirá. Como opción podemos definir el idioma del texto de esas columnas para las búsquedas, si no lo especificamos se usará el idioma por defecto de la instancia. Esto es importante si tenéis el servidor en inglés pero los datos en español, por ejemplo. Esta opción de language admite tanto el alias como el lcid de los idiomas de la vista del sistema sys.syslanguages.

Otro de los aspectos clave y que es obligatorio es definir un índice de referencia con la clave para nuestro nuevo índice FullText. Debe ser una clave única que no admita valores nulos. Para un mejor rendimiento se recomienda que sea un identificador único numérico. También debemos definir el catálogo sobre el que se creará el índice. Si no definimos el catálogo se usará el por defecto y si no hay uno por defecto veremos un bonito error, así que, aseguraos de definirlo bien.

Para terminar con esta sección de creación e índices FullText es importante destacar la opción de Change_Tracking que definirá la propagación de nuestro índice. Esto significa que define el comportamiento cuando hay una modificación de la tabla (Insert, Update o Delete). Por defecto está en modo AUTO y los cambios se propagan de la tabla al índice FullText en tiempo real pero podemos definirlo en modo manual y que solo se propaguen con una sentencia SQL que ejecutaremos a voluntad o programaremos en un job. La sentencia para propagar los cambios de la tabla al índice es:

Palabras irrelevantes

Como podéis imaginar, indexar todo un texto puede suponer unos requisitos de espacio tremendos, para evitar esto en la medida de lo posible SQL Server implementa lo que se llaman las palabras irrelevantes y las listas de palabras irrelevantes (stopword y stoplist). Si os habéis fijado antes, a la hora de crear un índice FullText podíamos definir una de estas stoplist.

Palabras irrelevantes

Una palabra irrelevante puede ser por ejemplo un código que guardamos pero que no se usa o palabras que sí tienen significado lingüístico pero que no son relevantes para las búsquedas como podrían ser preposiciones y otras. Por ejemplo en español no puede que no queramos indexar las palabras “un”, “y”, “el”, «de «, «hasta «, etc.

Listas de palabras irrelevantes

Para poder gestionar las palabras irrelevantes SQL Server usa unos objetos que se llaman lista de palabras irrelevantes o stoplists. Podemos encontrarlos desplegando la carpeta almacenamiento dentro de la base de datos (mirad en la imagen de antes). Para crear nuestras propias stoplists podemos hacerlo desde este apartado de SSMS o con la sintaxis CREATE FULLTEXT STOPLIST.

Mantenimiento de índices FullText 

Como ya adelantamos en el artículo de ayer, el mantenimiento de los índices FullText se realiza sobre los catálogos. Para ello podemos hacerlo desde el SSMS haciendo click derecho sobre el catálogo y dando a Rebuild o por T-SQL. Si lo hacemos por T-SQL tendremos la posibilidad de reorganizar los índices sin necesidad de reconstruirlos. Si optamos por un REBUILD se borrarán todos los índices del catálogo y se volverán a crear eliminando así la fragmentación. Puede ser que solo queramos hacer el mantenimiento a un índice, en este caso podemos borrarlo y crearlo de nuevo manualmente. La sintaxis para hacer el mantenimiento de un catálogo es:

Si os fijáis, con esta instrucción podríamos también definir este catálogo como el por defecto.

Conclusión

Hoy hemos aprendido cómo podremos lidiar con los FullText índices como DBAs, esto sumado a lo que vimos ayer y a lo que veremos en el próximo artículo sobre su uso es todo lo que necesitamos para controlar este tema. Si queréis profundizar más en detalle os recomiendo bucear por la documentación oficial que os he compartido y por todas las demás páginas de Microsoft sobre los índices de texto completo. A mi me parece un mundo apasionante y del que poca gente conoce todos los detalles. ¿Quién sabe? Igual algún día tener estos conocimientos puede marcar la diferencia para el trabajo de vuestros sueños.

Espero que este artículo te haya proporcionado una visión profunda de los índices FullText o de texto completo en SQL Server. Como siempre, te animo a experimentar con estas técnicas y a explorar todas las posibilidades que ofrecen. Si tenéis alguna duda o sugerencia, podéis dejarla en Twitter, por mail o dejarnos un mensaje en los comentarios. Y recuerda que también tenemos un grupo de LinkedIn y un canal de YouTube a los que te puede unir. ¡Hasta la próxima!

Publicado por Roberto Carrancio en Índices, Rendimiento, SQL Server, 0 comentarios

Índices de texto completo (Full-Text Indexes)

Volvemos a la carga con un artículo sobre índices, uno de los temas más importantes para el rendimiento de nuestras bases de datos y por ello sobre lo que más contenido tenemos en el blog. Si no has visto los artículos anteriores los tienes todos aquí. A estas alturas no es una sorpresa para nadie que diga que los índices son nuestros mejores aliados para optimizar las consultas y mejorar el rendimiento. Hoy, vamos a sumergirnos en el fascinante mundo de los índices de texto completo o Full-Text index en SQL Server. Este tipo de índice especial y no tan conocido en SQL Server nos va a permitir buscar en grandes cadenas de texto que, sin estos índices siempre es peor que un dolor de muelas.

¿Qué son los Índices de Texto Completo?

Los índices de texto completo son un tipo especial de índice de SQL Server que nos proporciona una solución eficaz para buscar palabras y frases dentro de una gran cantidad de datos de texto en SQL Server. A diferencia de los índices tradicionales, que se basan en la comparación de valores, los índices de texto completo nos permiten realizar búsquedas complejas en textos largos y no estructurados.

Creación de Índices de Texto Completo

Crear un índice de texto completo en SQL Server es un proceso sencillo. Primero, necesitamos una columna con un tipo de datos de texto. Luego, antes de poder crear en índice necesitaremos un catálogo de texto completo. Una vez creado el catálogo podremos crear nuestros índices de texto completo en sí. 

La creación de catálogos es un aspecto fundamental para los índices de texto completo y de cómo los estructuremos ya que nos va a permitir organizarlos y va a afectar al rendimiento futuro de nuestras tareas de mantenimiento.

Uso de Índices de Texto Completo

Una vez creado el índice de texto completo, podemos utilizar la cláusula CONTAINS en nuestras consultas para buscar palabras o frases específicas. También podemos usar la cláusula FREETEXT para realizar búsquedas más generales.

Desventajas de los Índices de Texto Completo

Los índices de texto completo en SQL Server son una herramienta poderosa, pero como cualquier tecnología, tienen sus limitaciones y desventajas. Aquí vamos a nombrar algunas de las más importantes:

Espacio Adicional

Los índices de texto completo ocupan espacio adicional en el disco. Esto puede ser significativo en bases de datos con muchas tablas grandes y varios índices creados. Por lo tanto, es importante considerar el equilibrio entre el rendimiento de la consulta y el uso del espacio en disco.

Rellenado de Índices

El proceso para crear y mantener un índice de texto completo se denomina rellenado (o rastreo). Hay tres tipos de rellenado de índice de texto completo: rellenado completo, rellenado basado en el seguimiento de cambios, y rellenado incremental basado en una marca de tiempo. Este proceso puede ser costoso en términos de recursos y tiempo, especialmente para bases de datos grandes.

Mantenimiento de Índices de Texto Completo

Como cualquier otro índice, los índices de texto completo requieren un mantenimiento regular para garantizar su eficiencia. SQL Server proporciona varias herramientas y técnicas para ayudarnos en esta tarea. Al igual que en el resto de tipos de índices estas son REORGANIZE y REBUILD. Sin embargo, en el caso particular de estos índices las tareas de mantenimiento se realizan sobre el catálogo afectando a todos los índices incluidos y no se puede hacer sobre un único índice a petición. Siempre nos queda la opción de eliminar el índice y volverlo a crear pero no parece una opción aceptable. Por si esto fuera poco es un proceso que no está incluido en las principales soluciones de mantenimiento como OLA Hallengren.

Recomendaciones de rendimiento

Como acabamos de mencionar, optimizar el rendimiento de los índices de texto completo en SQL Server puede ser un desafío. Vamos a ver las mejores recomendaciones que pueden ayudarnos:

Arquitectura y Mantenimiento

Es una buena idea limitar la selección de columnas de clave de texto completo a una columna pequeña. Aunque se admite una columna de 900 bytes, se recomienda usar una columna de clave menor en un índice de texto completo, int y bigint ofrecen el mejor rendimiento.

Podremos reorganizar el catálogo de texto completo utilizando ALTER FULLTEXT CATALOG REORGANIZE. Esto debe hacerse antes de realizar pruebas de rendimiento, ya que la ejecución de esta instrucción produce una mezcla maestra de los índices de texto completo del catálogo.

Uso y consultas

Siempre es mejor combinar varios predicados CONTAINS en un predicado CONTAINS. En SQL Server puedes especificar una lista de columnas en la consulta CONTAINS.

Si solo necesitas información de clave de texto completo o de clasificación, usa CONTAINSTABLE o FREETEXTTABLE en lugar de CONTAINS o FREETEXT, respectivamente.

Para limitar los resultados y aumentar el rendimiento, usaremos el parámetro top_n_by_rank de las funciones CONTAINSTABLE y FREETEXTTABLE top_n_by_rank permite volver a recuperar solo las coincidencias más pertinentes.

Comprobar el Plan de Consultas

Y como siempre, deberemos comprobar constantemente el plan de consultas de texto completo para asegurarnos de que se selecciona el plan de combinaciones adecuado. Usaremos una sugerencia de consulta o forzaremos un plan de ejecución en Query Store si es necesario.

Conclusión

Los índices de texto completo son una herramienta potentísima en SQL Server que nos permite realizar búsquedas eficientes en grandes volúmenes de datos de texto. Aunque su creación y mantenimiento pueden requerir un poco de esfuerzo adicional, los beneficios que aportan en términos de rendimiento y flexibilidad de las consultas valen la pena.

Esperamos que este artículo te haya proporcionado una visión profunda de los índices de texto completo en SQL Server. Como siempre, te animamos a experimentar con estas técnicas y a explorar todas las posibilidades que ofrecen. Si tenéis alguna duda o sugerencia, podéis dejarla en Twitter, por mail o dejarnos un mensaje en los comentarios. Y recuerda que también tenemos un grupo de LinkedIn y un canal de YouTube a los que te puede unir. ¡Hasta la próxima!

Publicado por Roberto Carrancio en Índices, Rendimiento, SQL Server, 3 comentarios

Protegiéndonos con Microsoft Defender para SQL Server

En el mundo digital de hoy, la seguridad de los datos es primordial. Como profesionales de la base de datos, entendemos la importancia de proteger nuestros activos más valiosos: nuestros datos. La creciente proliferación y sofisticación de las amenazas cibernéticas y la prevalencia de los ataques dirigidos a las bases de datos hacen que la necesidad de soluciones de seguridad robustas sea más importante que nunca. Hoy, vamos a explorar una herramienta que nos ayuda a hacer precisamente eso: Microsoft Defender para SQL Server.

¿Por qué necesitamos Microsoft Defender para SQL Server?

Las bases de datos son a menudo el objetivo de los ciberdelincuentes debido a la valiosa información que contienen. Con el aumento de las amenazas y la constante evolución de las tácticas de los ciberdelincuentes, es esencial contar con una solución de seguridad que pueda mantenerse al día. Ya dedicamos hace unas semanas un artículo a los ataques SQL Injection, que son los más predominantes, y que puedes leer aquí. Aquí es donde entra en juego Microsoft Defender para SQL Server que gracias a aprovechar todo el potencial de Azure nos permite protegernos de este y muchos otros escenarios.

¿Qué es Microsoft Defender para SQL Server?

Microsoft Defender para SQL Server es una solución de seguridad integral diseñada para proteger nuestras bases de datos SQL Server ya esten On Premise, en la nube de Azure o en otras nubes comerciales como ASW o GCP. Proporciona una capa adicional de protección, ayudándonos a detectar y responder a amenazas potenciales antes de que puedan causar daño.  Pero, ¿qué significa esto en términos técnicos?

Características Clave

Microsoft Defender para SQL Server viene con una serie de características que lo hacen una opción atractiva para cualquier organización que busque mejorar su postura de seguridad. Además integrar una detección de amenazas, como estamos acostumbrados en los antivirus convencionales, incluye una evaluación de vulnerabilidades que nos permitirá detectar nuestros puntos flacos en la seguridad de nuestras bases de datos.

Detección de Amenazas

Una de las características más destacadas de Microsoft Defender para SQL Server es su capacidad para detectar amenazas en tiempo real. Utiliza algoritmos avanzados para identificar comportamientos sospechosos y alertarnos de posibles problemas. Esto incluye la detección de inyecciones SQL, anomalías en el comportamiento de la base de datos y configuraciones inseguras.

Integración con Azure

Como parte de la familia de productos de Azure, Microsoft Defender para SQL Server se integra perfectamente con otros servicios de Azure, lo que permite una visión unificada de la seguridad en toda nuestra infraestructura de Azure. Esto nos permite tener una visión unificada de nuestra seguridad en toda nuestra infraestructura de Azure. Esto significa que podemos ver y gestionar las alertas de seguridad de todas nuestras bases de datos SQL Server desde un único panel.

Cobertura de Microsoft Defender para SQL Server

Microsoft Defender para SQL Server ofrece una amplia cobertura para proteger nuestras bases de datos. Esto incluye la protección contra ataques de inyección SQL, la detección de anomalías en el comportamiento de la base de datos y la identificación de configuraciones inseguras. Además, proporciona recomendaciones de seguridad personalizadas basadas en nuestras configuraciones y patrones de uso específicos.

Entre las coberturas que  Microsoft Defender para SQL Server ofrece una amplia cobertura para proteger nuestras bases de datos podemos encontrar:

  • Protección contra ataques de inyección SQL: Microsoft Defender para SQL Server utiliza técnicas de aprendizaje automático para detectar patrones de consulta SQL anómalos que podrían indicar un intento de inyección SQL.
  • Detección de anomalías en el comportamiento de la base de datos: Microsoft Defender para SQL Server puede identificar comportamientos anómalos, como un aumento repentino en el volumen de transacciones o cambios inusuales en los patrones de acceso a los datos.
  • Identificación de configuraciones inseguras: Microsoft Defender para SQL Server puede identificar configuraciones que podrían hacer que nuestras bases de datos sean más vulnerables a los ataques, como la falta de cifrado o el uso de contraseñas débiles.

Evaluación de Vulnerabilidades con Microsoft Defender para SQL Server

Otra de las características esenciales de Microsoft Defender para SQL Server es su capacidad para realizar evaluaciones de vulnerabilidades como ya hemos comentado. Lo más interesante de esta herramienta integrada es que analizando las configuraciones de nuestras bases de datos es capaz de descubrir e indicarnos cómo remediar posibles vulnerabilidades en la base de datos. Las evaluaciones de vulnerabilidades proporcionan una visión general del estado de seguridad de nuestras máquinas SQL y detalles de cualquier hallazgo de seguridad.

La evaluación de vulnerabilidades emplea una base de conocimientos de reglas que señalan vulnerabilidades de seguridad y resaltan desviaciones de las mejores prácticas, como configuraciones incorrectas, permisos excesivos y datos sensibles sin protección. Las reglas se basan en las mejores prácticas recomendadas por Microsoft y se centran en los problemas de seguridad que presentan los mayores riesgos para nuestra base de datos y nuestros datos.

Además, cuando habilitamos el plan Defender para Azure SQL en Defender for Cloud, Defender for Cloud habilita automáticamente la Protección Avanzada contra Amenazas y la evaluación de vulnerabilidades con la configuración express para todas las bases de datos Azure SQL en la suscripción seleccionada. Esto nos permite realizar evaluaciones de vulnerabilidades a demanda para ver los hallazgos actuales.

Conclusión

Microsoft Defender para SQL Server es una herramienta valiosa para cualquier administrador de bases de datos que busque mejorar la seguridad de sus bases de datos SQL Server en la nube. Proporciona una serie de características de seguridad avanzadas y se integra perfectamente con Azure Security Center, lo que facilita la gestión de la seguridad de nuestras bases de datos. Aunque no es una solución de seguridad completa en sí misma, es un componente importante de una estrategia de seguridad de bases de datos efectiva.

Espero que este artículo te haya sido útil y que te ayude a tener mayor control sobre tus servidores SQL Server. Te animo a investigar más y definir nuevas alertas que puedan resultarte interesantes. Una vez hecho, puedes dejarlo en los comentarios y, entre todos, seguro que aprendemos algo nuevo. Si tenéis alguna duda o sugerencia, podéis dejarla en Twitter, por mail o dejarnos un mensaje en los comentarios. Y recuerda que también tenemos un grupo de LinkedIn y un canal de YouTube a los que te puede unir. ¡Hasta la próxima!

Publicado por Roberto Carrancio en Cloud, SQL Server, 2 comentarios

Dimensionamiento correcto de un servidor

En nuestro trabajo como administradores de bases de datos, una de las tareas más cruciales y desafiantes a las que nos vamos a enfrentar es calcular el dimensionamiento de un servidor SQL Server. Este proceso implica determinar la cantidad de recursos necesarios para que el servidor funcione de manera óptima, teniendo en cuenta factores como el número de usuarios, la cantidad de datos y las operaciones de la base de datos.

Consideraciones Iniciales

El dimensionamiento adecuado de un servidor SQL Server no es una tarea sencilla. Requiere un conocimiento profundo de las características y capacidades del servidor, así como de las necesidades y demandas de la base de datos y las aplicaciones que se ejecutan en él. Antes de sumergirnos en cálculos y métricas, es esencial entender la carga de trabajo que manejará nuestro nuevo servidor. Esto implica analizar el volumen de transacciones, la concurrencia de usuarios, y los patrones de acceso a los datos. Solo con un conocimiento profundo de estas variables podemos comenzar a esbozar los requisitos de nuestro servidor. 

Si el nuevo servidor se va a usar para sustituir uno ya existente lo vamos a tener mucho más fácil, podremos basarnos en el estado actual y analizar sus puntos flacos para tratar de mejorarlos. Hablamos de migraciones en este otro artículo.

El verdadero reto lo tendremos cuando nos enfrentemos a un escenario nuevo, desde 0. En este caso, será crucial la colaboración de los equipos responsables de los datos o de las aplicaciones, en especial de un buen project manager, además de otros departamentos de negocio que nos puedan indicar previamente las expectativas de carga de trabajo y necesidades de almacenamiento.  En un mundo ideal, todas estas necesidades estarían especificadas en la documentación del proyecto y no tendríamos que hacer más preguntas. Pero, como eso no es lo que nos solemos encontrar (y menos mal, porque así tengo algo de lo que escribiros), vamos a analizar en profundidad que debemos tener en cuenta.

Aspectos a evitar

A lo largo de mis años de experiencia me he enfrentado a las suficientes migraciones y nuevos despliegues como para haber elaborado una lista con los aspectos que si o si debo evitar si quiero llevar el proyecto a buen puerto. Os comparto un pequeño resumen:

  • Subestimar el crecimiento: Y no solo me refiero a los datos, eso es quizá lo de menos. Debemos tener una idea clara de las necesidades de recursos del servidor para que un futuro aumento de la carga de trabajo no nos degrade el rendimiento o, directamente, tumbe el servicio.
  • Falta de monitorización: Es imprescindible monitorizar completamente el servidor tanto antes de la migración si es el caso, como tras la implementación, SIEMPRE. Si disponemos de un servidor antiguo que tenemos que migrar, no monitorizarlo y conocer su comportamiento completamente nos llevará a problemas en un futuro. No hagamos conjeturas, y apoyémonos en datos. 
  • No conocer los objetivos comerciales: Este punto está muy ligado al primero pero tiene su razón de ser como punto independiente. Puede que el equipo de desarrollo haya desplegado una aplicación para los 500 clientes actuales y esos sean los datos que tenemos nosotros pero, si desde la dirección se han marcado el objetivo de doblar esa cifra cada ejercicio, pronto nuestro servidor no dará más de sí.
  • Sobreaprovisionamiento: Puede parecer una buena opción visto lo visto pero nada más lejos de la realidad. Aprovisionar más recursos de los que necesitamos o vamos a necesitar a corto plazo será un malgasto de recursos y no nos dejará en buen lugar como profesionales.

Cómo calcular un dimensionamiento correcto

Ahora que ya sabemos los puntos clave que debemos evitar vamos a ver uno a uno como debemos hacerlo.

Carga de trabajo

Como ya hemos dicho, comprender la carga de trabajo que afrontará nuestro servidor es el aspecto fundamental para un correcto dimensionamiento. Si hablamos de un servidor completamente nuevo nos tendremos que basar en las necesidades que nos indiquen los responsables del proyecto y cobrarán más sentido el resto de apartados. Si por el contrario estamos sustituyendo un servidor existente este punto es de vital importancia. Usaremos todos los recursos que tengamos a nuestra disposición y en ocasiones un trabajo de monitorización previo nos facilitará el trabajo.

En este sentido, a mi me gusta tener siempre en mis servidores un proceso que controle el crecimiento de los ficheros de base de datos (usando la vista sys.master_files por ejemplo) y que lo persista en una tabla de configuración. De esta manera a la hora de calcular el dimensionamiento podremos hacernos una idea clara del histórico de crecimiento de nuestras bases de datos. 

Para calcular las necesidades de otros recursos echaremos mano de las DMV que SQL Server pone a nuestra disposición, de Query Store o del monitor de rendimiento de Windows. Prestaremos especial atención a los tiempos de espera de nuestras consultas para, en la medida de lo posible, acabar con esos cuellos de botella.

Estrategia proactiva

Las bases de datos no son objetos estáticos, están continuamente cambiando y como tal, nosotros tendremos que monitorizar y verificar que las previsiones iniciales que hicimos son correctas. No solo hablo de las pruebas antes del “go live” sino de todo el ciclo de vida del servidor. Una buena monitorización nos permitirá pronosticar una futura necesidad de recursos y anticiparnos a ese dimensionamiento antes de que exista degradación en el rendimiento del servidor. 

El mercado está repleto de soluciones integrales de monitorización de rendimiento de SQL Server pero, cuando el presupuesto no lo permite, tendremos que ser creativos con las soluciones nativas sin dejar de lado esta tarea. Nuevamente las DMV de SQL Server, Query Store y el monitor de rendimiento de Windows serán nuestros aliados. Además, si persistimos estos datos, seremos capaces de analizar tendencias y predecir comportamientos en un futuro (de esto sabe mucho la gente de BI).

Objetivos Comerciales y dimensionamiento

No trabajamos solos, en la mayoría de los casos nuestras bases de datos son una pieza clave para el desempeño de la actividad de negocio. Sería de necios pensar que podemos hacer nuestro trabajo sin alinearnos con el resto de departamentos e ignorando los objetivos comerciales de nuestra organización. En este sentido, cuanto mayor sea nuestro conocimiento del sector, de la empresa en particular y de sus objetivos mejores previsiones podremos hacer.

Igualmente, esto va en los dos sentidos, es nuestra responsabilidad hacernos valer y que los jefes que toman las decisiones sepan que tienen que contar con nosotros. He trabajado en sitios donde no era así, se tomaban decisiones de negocio sin comunicar los objetivos comerciales al departamento de IT y sin trasladar las necesidades de crecimiento. ¿De verdad piensas que tus sistemas están preparados para asumir de la noche a la mañana una fusión que duplique la cantidad de clientes? 

Podríamos resumir este apartado en tres aspectos fundamentales, conoce los objetivos comerciales, involucra a todas las partes interesadas en la planificación y pronostica de manera adecuada la capacidad de los sistemas antes de que sea tarde. 

Escalabilidad, prepárate para un ajuste en el dimensionamiento

Como último punto a tener en cuenta pero no por ello menos importante tenemos que ser capaces de diseñar un sistema capaz de crecer. Ya hemos dicho que nuestras bases están vivas y cambian con el tiempo, normalmente, si todo va bien, crecerán. También hemos visto que sobredimensionar de primeras un sistema puede ser un malgasto de recursos. Aquí es donde entra en juego la escalabilidad. No voy a profundizar más en el concepto porque ya le hemos dedicado un artículo completo al tema que puedes leer aquí.

Es importante que conozcas y que trabajes conjuntamente con el equipo de infraestructura para brindar a tus servidores de esta capacidad. Y no solo con sistemas, confirma con los equipos de desarrollo si sus aplicativos están preparados para un escalado horizontal. Si es así, considera planificar nuevas máquinas, licencias y todo lo necesario para asumir el crecimiento futuro, aunque solo sea una planificación y no se implante a corto plazo es importante tenerlo documentado. 

Sin embargo, este escenario no es lo más común. Normalmente priorizaremos un escalado vertical, aumentando los recursos de nuestro servidor siempre que sea posible. Aquí entra en juego ese trabajo conjunto con los compañeros de sistemas del que estábamos hablando antes. No es lo mismo un escalado vertical en una máquina física que en una virtual o en la nube. Asegúrate de que tienes el presupuesto y la capacidad para crecer y hacer frente a las futuras capacidades del servicio.

Conclusión

El dimensionamiento adecuado de un servidor SQL Server es esencial para garantizar su rendimiento y eficiencia. Al tener en cuenta factores como la carga de trabajo, el rendimiento, la capacidad de almacenamiento y la concurrencia, y al utilizar las herramientas y técnicas adecuadas, podemos hacer una estimación precisa de los recursos necesarios para nuestro servidor. Aun así, el trabajo no termina ahí, las bases de datos están en constante crecimiento y tenemos que ser capaces de adelantarnos a las necesidades de recurso y redimensionar el servidor correctamente. 

Espero que este artículo te haya sido útil y que te ayude a dimensionar correctamente tus SQL Server.  Si tenéis alguna duda o sugerencia, podéis dejarla en Twitter, por mail o dejarnos un mensaje en los comentarios. Y recuerda que también tenemos un grupo de LinkedIn y un canal de YouTube a los que te puede unir. ¡Hasta la próxima!

Publicado por Roberto Carrancio en Otros, 1 comentario

Active Directory (AD) para DBAs de SQL Server

En el mundo de la administración de bases de datos, el conocimiento técnico es la base para cualquier DBA y cuanto mayor conocimiento sobre el SGBD con el que trabajamos mejor podremos desempeñar nuestro trabajo. Pero, ¿qué pasa con los sistemas y servicios que interactúan directamente con nuestras bases de datos? Aquí es donde entra en juego, por ejemplo, el Active Directory (AD), una pieza clave en la infraestructura de cualquier organización y que si utilizamos SQL Server tendremos que integrar en nuestro dia a dia. Comprender cómo AD y los sistemas operativos se entrelazan con SQL Server no solo es deseable, sino esencial para un desempeño experto y seguro.

¿Qué es AD y por qué es importante para los DBAs?

Active Directory (AD) es un directorio de servicios centralizado que gestiona las identidades y las relaciones de seguridad dentro de una red. Por identidades nos referimos a los objetos de nuestra organización, desde cuentas de usuario y servicios hasta máquinas cliente y servidores. Estas entidades se organizan en base a su pertenencia a grupos de seguridad y entidades organizativas sobre las que, posteriormente, podremos gestionar los permisos.

Para un DBA, entender los principios de AD es crucial, ya que SQL Server se integra completamente con este servicio para la autenticación y autorización de usuarios. Un dominio de AD bien configurado garantiza que solo los usuarios autorizados tengan acceso a los datos sensibles, manteniendo la integridad y la seguridad de la información. Además el hecho de poder gestionar grupos de seguridad nos va simplificar mucho la tarea de asignar permisos a los usuarios y su posterior mantenimiento.

Conceptos básicos de AD para DBAs

Aunque como DBAs no es parte de nuestras responsabilidades administrar el directorio activo (AD), es importante que estemos familiarizados con sus conceptos ya que, como hemos visto, están directamente relacionados con la gestión de la seguridad de nuestras bases de datos.

Dominios de AD

Un dominio es una unidad lógica de organización en un Directorio Activo. Cada dominio tiene una base de datos de seguridad que almacena información de seguridad sobre objetos como usuarios, grupos y equipos. Como ya hemos visto, que nuestro SQL Server sea parte del dominio nos facilita una administración centralita de usuarios y políticas de seguridad.

Controladores de Dominio (DC)

Un Controlador de Dominio (DC) es un servidor que responde a solicitudes de autenticación y mantiene el directorio de dominio. Los DC son responsables de permitir el acceso a los recursos de red y de aplicar las políticas de seguridad del dominio. SQL Server puede delegar en el controlador de dominio la gestión de usuarios mejorando la seguridad y facilitandonos la administración.

Unidades Organizativas (OU)

Las Unidades Organizativas (OU) son contenedores dentro de un dominio que pueden contener usuarios, grupos, equipos y otras OU. Las OU se utilizan para organizar y administrar objetos dentro de un dominio. Por nuestra parte, tenemos que saber que podemos agrupar servidores y/o usuarios en OU para centralizar ciertas tareas de administración.

Protocolos de Autenticación (Kerberos y NTLM)

Kerberos y NTLM son protocolos de autenticación utilizados por los DC para verificar la identidad de los usuarios. Kerberos es un protocolo basado en tickets, mientras que NTLM utiliza un desafío-respuesta. SQL Server está preparado para trabajar con ambos protocolos garantizando un acceso seguro a los datos.

Usuarios y Grupos de AD

Los usuarios son cuentas que representan a individuos o servicios en la red. Los grupos son colecciones de usuarios que comparten los mismos derechos de acceso a los recursos. Como ya hemos comentado, SQL Server se aprovecha de esta capacidad para la autenticación y autorización de usuarios. Gracias a los grupos, podremos gestionar accesos de varios usuarios a recursos de manera simultánea.

Nombre Principal de Servicio (SPN)

El Nombre Principal de Servicio (SPN) es un identificador único asignado a cada servicio que se ejecuta en un servidor. Los SPN se utilizan en la autenticación Kerberos para asociar un servicio con una cuenta de servicio. Para que SQL funcione con Kerberos deberemos registrar el SPN para la cuenta de servicio de SQL Server.

Políticas de Seguridad (GPO)

Las Políticas de Grupo (GPO) son reglas que se pueden aplicar a usuarios o equipos dentro de un dominio. Las GPO se utilizan para controlar el entorno de trabajo de los usuarios y los equipos. Es muy común que SQL Server se beneficie de las GPO de longitud y complejidad de contraseñas, por ejemplo.

Confianzas

Las confianzas son relaciones que permiten a los usuarios de un dominio acceder a recursos en otro dominio. Como DBAs esto nos va a ahorrar mucho trabajo al no necesitar duplicar usuarios.

Catálogo Global de AD

El Catálogo Global es una base de datos distribuida que contiene una copia parcial de todas las bases de datos de dominio en un bosque. Se utiliza para acelerar las consultas dentro del bosque. Tenemos que saber que tanto nuestros servidores como los usuarios pertenecen a este catálogo global.

Bosque

Un bosque es una colección de uno o más dominios de Directorio Activo que comparten un esquema común. Esto nos va a permitir gestionar varios SQL Server de diferentes dominios bajo una configuración global.

Esquema

El esquema es la definición de todos los objetos y atributos que se pueden crear en el Directorio Activo. Nuestros SQL Server serán capaces de gestionar las extensiones de los esquemas y nos permitirán llevar a cabo configuraciones especializadas o cuando necesitemos cumplir con ciertos requisitos de integración.

Protocolo Ligero de Acceso a Directorios (LDAP)

LDAP es un protocolo de red utilizado para acceder y gestionar el Directorio Activo. LDAP permite a los clientes buscar y manipular entradas en el directorio. SQL Server utiliza LDAP para acceder en modo consulta a la información de AD y así validar las credenciales de usuarios o la pertenencia a grupos.

Conclusión

En este post hemos podido adentrarnos en los conceptos básicos de AD, sin embargo os recomiendo profundizar y probar. Para muchas cosas necesitaréis la ayuda del administrador de directorio activo de vuestra organización pero a la larga lo vais a agradecer. Ser un DBA de SQL Server con conocimientos avanzados en AD y sistemas no solo mejora la seguridad y la eficiencia de nuestros servidores, sino que también elevará nuestro valor profesional en el mercado. La integración de estos conocimientos permite enfrentar desafíos complejos y asegurar que las bases de datos sean confiables, seguras y tengan un buen desempeño. Nosotros, como expertos en la materia, debemos estar siempre al tanto de las últimas tendencias y mejores prácticas para garantizar la excelencia operativa en un entorno de alta criticidad.

Espero que este artículo te haya sido útil y que te ayude a tener mayor control sobre tus servidores SQL Server. Te animo a investigar más y definir nuevas alertas que puedan resultarte interesantes. Una vez hecho, puedes dejarlo en los comentarios y, entre todos, seguro que aprendemos algo nuevo. Si tenéis alguna duda o sugerencia, podéis dejarla en Twitter, por mail o dejarnos un mensaje en los comentarios. Y recuerda que también tenemos un grupo de LinkedIn y un canal de YouTube a los que te puede unir. ¡Hasta la próxima!

Publicado por Roberto Carrancio en SQL Server, 0 comentarios

Monitorización con Alertas del Agente en SQL Server

Llegan las vacaciones de semana santa y a todos nos gusta desconectar. Aun así, no debemos descuidar la vigilancia sobre nuestros servidores, sobre todo los más críticos. En el mundo de la informática en general y, de la administración de bases de datos en particular, estar al tanto de lo que sucede en nuestros sistemas es crucial. Una actuación sencilla a tiempo nos puede ahorrar una larga intervención para corregir una incidencia en un futuro. Es por esto que la monitorización nativa de SQL Server a través de las alertas del agente es un aliado fundamental de cualquier DBA. En el mercado existen multitud de herramientas que ofrecen una ventana directa al rendimiento y la salud de nuestras bases de datos pero suelen ser costosas y complejas de implementar, mientras que las alertas de SQL, sin ser la solución definitiva, nos brindan una excelente solución básica pero efectiva.

¿Qué son las Alertas del Agente?

Las alertas del agente son un conjunto de respuestas automatizadas que se activan ante eventos específicos en SQL Server. Estos eventos pueden ser desde un simple rendimiento subóptimo hasta errores críticos que requieren atención inmediata. Este sistema de monitorización vigila nuestro SQL Server en busca de los desencadenadores que hayamos definido y, gracias al correo electrónico de base de datos es capaz de hacernos llegar el aviso.

También dispondremos de una opción para ejecutar automáticamente un job que nos será muy útil en caso de tener automatizado un procedimiento de resolución automático para ciertos eventos controlados.

Monitorización con alertas de SQL Server

La monitorización nativa utiliza herramientas integradas en SQL Server para mantener un ojo vigilante sobre los procesos críticos. Esto incluye el seguimiento de bloqueos, la supervisión del rendimiento de las consultas y la detección temprana de posibles problemas. 

Configuración Óptima para DBAs

Si estamos familiarizados con o tenemos cierta experiencia en SQL Server, configurar alertas del agente es un proceso familiar y sencillo. Sin embargo, es importante ajustar bien los parámetros que las desencadenan para que las alertas sean significativas y proporcionen información valiosa sin saturarnos con falsos positivos. Un exceso de alertas puede llegar a ser igual a no tener alertas ya que corremos el riesgo de terminar perdiendo información sobre incidentes graves entre tanto aviso. 

Caso práctico de configuración de alertas

Las alertas en SQL Server se pueden configurar tanto desde la interfaz gráfica como por script. En el caso de la interfaz gráfica, lo encontraremos colgando del agente de SQL Server en nuestro Management Studio. La ventana de configuración de las alertas tiene este aspecto:

Como veis tenemos un apartado general en el que definiremos el nombre de nuestra alerta y cuál será su desencadenante. Para el tipo “SQL Server error alert”, que es el que más nos interesa, podremos decidir si afecta a una base de datos en concreto o a todas y si se activará por un número de error específico o por todos los que respondan a un nivel de gravedad. También podemos añadir un filtro extra por texto del mensaje. Existen otros tipos de alerta por condiciones de rendimiento o por eventos WMI de Windows. Disponemos también de otros dos apartados en los que configurar la respuesta a estas alertas y sus opciones.

Qué errores monitorizar con alertas

Para poder configurar alertas en base a errores de SQL Server es imprescindible conocer el significado de los niveles de gravedad. Estos niveles van desde el 0 hasta el 25 y se dividen de la siguiente manera. Del 0 al 10 representan mensajes informativos sobre el estado del servidor. Del 11 al 16 son errores que pueden ser corregidos por los usuarios como que un objeto no existe o código SQL mal escrito por ejemplo. A partir de la gravedad 17 si que requerirán nuestra intervención como DBAs y son estos los que os recomiendo monitorizar.

  • Gravedad 17 a 19: Indica errores de software que no pueden ser corregidos por el usuario. Como falta de recursos para completar una consulta.
  • Gravedad 20 a 24: Indica problemas del sistema y son errores irrecuperables, lo que significa que ya no está en ejecución la tarea del motor de base de datos que esté ejecutando una instrucción o lote.
  • Gravedad 25: Error desconocido, aquí irá todo error no controlado por el motor de base de datos.

Además de los errores basados en gravedad yo monitorizo también los códigos de error específicos 823, 824 y 825 que alertan de falta de espacio en disco y el código 1480 que indica un cambio de rol del Always On

¿Os parecen muchas cosas? No os preocupéis, os dejo aquí el script para crear directamente estas alertas:

Conclusión

Con una configuración adecuada y un uso correcto de las alertas del agente, podemos asegurar que nuestros sistemas de bases de datos operen con la máxima eficiencia. La monitorización nativa no es solo una herramienta, es una parte integral de nuestra estrategia proactiva para mantener la salud de SQL Server. Es cierto que, al usar una monitorización en local, se nos escaparán eventos más graves como la caída del propio servidor pero es un buen punto de partida y, sobre todo, es mejor que no tener nada.

Espero que este artículo te haya sido útil y que te ayude a tener mayor control sobre tus servidores SQL Server. Te animo a investigar más y definir nuevas alertas que puedan resultarte interesantes. Una vez hecho, puedes dejarlo en los comentarios y, entre todos, seguro que aprendemos algo nuevo. Si tenéis alguna duda o sugerencia, podéis dejarla en Twitter, por mail o dejarnos un mensaje en los comentarios. Y recuerda que también tenemos un grupo de LinkedIn y un canal de YouTube a los que te puede unir. ¡Hasta la próxima!

Publicado por Roberto Carrancio en SQL Server, 2 comentarios

VLF: Entendiendo el Log de SQL Server nivel pro

En nuestra constante búsqueda de optimización y eficiencia en el manejo de bases de datos, nos encontramos con una pieza clave en el rompecabezas de SQL Server: los Virtual Log Files (VLF). Estos componentes, aunque pequeños y a menudo pasados por alto, son fundamentales para el rendimiento y la gestión de nuestras bases de datos. Hoy, nos sumergimos en el mundo de los VLF para entender su función y cómo una gestión adecuada puede marcar la diferencia en nuestro trabajo diario como DBAs. Referenciando nuestro artículo anterior ¿Cómo funcionan los ficheros de Log de SQL Server?, podemos recordar que el log de transacciones juega un papel vital en la recuperación de datos y, los VLFs, como parte fundamental de los logs, tienen la misma importancia.

¿Qué son los VLF y por qué son importantes?

Los VLF son segmentos virtuales en los que se divide el archivo de log de transacciones de una base de datos en SQL Server. Es decir, SQL Server no trabaja con el fichero de log completo sino con pequeñas particiones del mismo. Cada vez que se crea o se expande un log, SQL Server lo divide en varios VLFs. La cantidad y el tamaño de estos VLF pueden tener un impacto significativo en el rendimiento de la base de datos, especialmente durante operaciones de recuperación y respaldo. En casos extremos, si tenemos el log muy particionado puede afectarnos también al rendimiento de nuestras transacciones. 

Gestión Efectiva de VLF

Para mantener un sistema saludable, es crucial gestionar adecuadamente los VLF. Un número excesivo de VLF pequeños puede causar lentitud en el proceso de recuperación de la base de datos, mientras que muy pocos VLF grandes pueden dificultar el proceso de respaldo. Por ello, encontrar el equilibrio correcto es esencial. Los VLF son los bloques de construcción de este log, y su gestión eficiente permite una recuperación más rápida y una mejor disponibilidad de la base de datos.

Una estrategia efectiva para la gestión de VLF implica monitorear su cantidad y tamaño regularmente. SQL Server proporciona herramientas que nos permiten visualizar y ajustar estos parámetros, como el deprecado comando DBCC LOGINFO o su nueva versión, la función sys.dm_db_log_info. Además, prácticas como el truncamiento regular del log y la expansión controlada del archivo de log ayudan a mantener un número óptimo de VLF.

Creación de VLFs

Hemos visto que el motor de SQL Server crea automáticamente los VLFs durante el crecimiento de los ficheros de logs, sin embargo, esto no significa que nosotros no podamos influir sobre ello. Simplemente tendremos que conocer qué reglas sigue SQL para crear VLFs para adaptarnos a ello. Antes de nada tenemos que especificar que las reglas de creación de VLFs han cambiado con SQL 2022 por lo que tanto para esta versión como para Azure tendremos que tenerlo en cuenta. Veamos cómo se crean los VLFs:

  • Cuando el crecimiento del archivo de log es menor a 64 Mb SQL creará 4 VLFs en versiones antiguas y solo 1 VLF en SQL 2022 y en Azure.
  • Si el crecimiento del archivo de log es igual o mayor a 64 Mb pero menor a 1 Gb se crearán 8 VLFs.
  • Si el crecimiento del archivo de log es igual o mayor a 1Gb se crearán 16 VLFs.

Cuantos VLFs tienen mis logs

Ya sabemos cómo se crean los VLFs y por qué podemos llegar a tener muchos en nuestros mecheros de logs pero, no os he dicho aún cómo comprobar en vuestras bases de datos cuantos VLFs teneis. Para ello usaremos el siguiente script. Y ahora la pregunta clave, ¿Cuántos VLF debería tener? La respuesta es depende, no hay una respuesta universal a esta pregunta. Personalmente creo que sobre 50 es una buena cifra pero dependerá en gran medida del tamaño del fichero de log. 

Hora de hacer números y corregir los VLF

Supongamos que nuestra base de datos tiene un log de 20Gb y hemos visto que por alguna mala práctica del pasado tenemos muchos VLF. Lo primero que tendremos que hacer es un shrink para reducir el log lo máximo posible. Una vez con el log en su tamaño mínimo vamos a volver a dimensionarlo a sus 20Gb originales pero siguiendo las buenas prácticas de VLF. Vamos a crear un número de VLF cercano a 50. Para ello no podemos dimensionar directamente en 20Gb porque solo nos crearía 16 VLF y serían muy grandes para ser administrados por SQL de manera óptima. Qué pasa si aumentamos 8 Gb iniciales, luego otros 8 y terminamos con un crecimiento de 4 Gb. Esto serían 3 crecimientos del fichero superiores a 1 Gb por lo que se nos crearían 16 VLF en cada “salto”, 16*3=48. Parece bastante razonable. Ahora, si el fichero puede necesitar crecer en un futuro, podría ser interesante hacer 3 crecimientos de 8 Gb lo que nos daría 24 Gb de log repartidos igualmente en 48 VLF (unos ficheros de 512 Mb cada uno, algo asumible).

Conclusión

La gestión de VLF no es solo una tarea de mantenimiento; es una oportunidad para maximizar el rendimiento de nuestras bases de datos. Al comprender la importancia de estos elementos y aplicar prácticas de gestión efectivas, podemos asegurar un sistema robusto y ágil. Los VLF son, sin duda, pequeños gigantes en el mundo de SQL Server, y su correcta administración está reservada a unos pocos DBAs expertos con gran pericia técnica, como vosotros ahora.

Espero que este artículo te haya sido útil. Si tenéis alguna duda o sugerencia, podéis dejarla en Twitter, por mail o dejarnos un mensaje en los comentarios. Y recuerda que también tenemos un grupo de LinkedIn y un canal de YouTube a los que te puede unir. ¡Hasta la próxima!

Publicado por Roberto Carrancio en Rendimiento, SQL Server, 0 comentarios