Ayer en el Twitter me preguntaban sobre el excesivo consumo de memoria RAM por parte de MSSQL Server y qué se podía hacer para evitarlo. No estuve muy interiorizado con el problema en sí, pero me sirvió para inspirarme y escribir un articulo más sobre búsqueda y corrección de problemas en la base de datos.

El consumo de RAM en SQL Server no siempre es un problema, ya que si se configuró para que consuma todos los recursos que están al alcance, lo hará. Ya que comenzará a guardar en caché las consultas que se ejecutan con mayor frecuencia para responder con mayor velocidad a la demanda. Pero no todo es color de rosa (Continuar Leyendo sobre Buscar cursores abiertos en T-SQL para optimizar recursos)

Continuando con los tips para optimizar nuestras querys SQL, trataremos unas de las clásulas que más ralentizan éstas. El operador LIKE.

La definición que exponen en la TechNet me gusta y dice asi:

Determina si una cadena de caracteres específica coincide con un patrón especificado. Un patrón puede contener caracteres normales y caracteres comodín. Durante la operación de búsqueda de coincidencias de patrón, los caracteres normales deben coincidir exactamente con los caracteres especificados en la cadena de caracteres. Sin embargo, los caracteres comodín pueden coincidir con fragmentos arbitrarios de la cadena. La utilización de caracteres comodín hace que el operador LIKE sea más flexible que los operadores de comparación de cadenas = y !=.

Como se tiene que trabajar con cadenas de texto, dentro de otras cadenas más grandes normalmente, es un proceso lento para la comparación. Muchas veces (Continuar Leyendo sobre Optimizar las querys con cláusula LIKE en SQL [SQL-Tunning])

Para realizar SQL Tunning a nuestras bases de datos, en la mayoría de los casos necesitaremos paciencia y tiempo para analizar con detenimiento como está funcionando todo, así en base a eso, determinar medidas de acción para la optimización.

Para ver el plan de ejecución de un query es muy sencillo en SSMS, podemos ver el Estimado y el Real:

Plan de Ejecución Estimado: Desde el Menú Consultas -> Mostrar Plan de Ejecución Estimado o con la combinación de teclas Ctrl + L. Esto no ejecutará la query sino más bien lo analizará y mostrará una aproximación del costo de su ejecución.

Plan de Ejecución Real: Desde el Menú Consultas -> Incluir Plan (Continuar Leyendo sobre Tutorial básico para interpretar el plan de ejecución de SQL Server)

Si bien este es un tema que todo DBA debe conocer obligatoriamente para poder realizar el tunning de su base de datos quiero usarlo para explicar algunos conceptos básico para los siguientes artículos que estoy preparando sobre optimización del rendimiento de los querys SQL y comprensión de los planes de ejecución.

Lo que veremos aplica a las versiones 2005 y 2008 de SQL Server, aunque una gran parte también para la versión 2000. De hecho que varios de los conceptos también aplica a otros motores del mercado, unos con menos y otros con más opciones de tunning. (Continuar Leyendo sobre Diferencias entre Indices Clustered y Non-Clustered en SQL Server)

Tanto desarrolladores como DBA’s  en algún momento nos llegamos a preguntar cual es la diferencia entre el Unique Constraint y el Unique Index, en gran manera ambos cumplen con la misma función y en la práctica en el 99%  de los casos no habrá diferencia si usamos uno u otro para impedir que se dupliquen valores en una o más columnas que componen al objeto.

De hecho que al crear el Unique Constraint el mismo crea por debajo otro Indice Unico nonclustered automáticamente. (Continuar Leyendo sobre Cual es la diferencia entre un Unique Index y Unique Constraint)

Leyendo mis RSS vi un artículo en grimpidev.wordpress.com que me gustó, sobre como liberar el consumo de la memoria RAM que utilizar el servicio de SQL Server.

Si bien es cierto que no es una función diseñada para tal efecto se puede utilizar como artificio para lograr éste objetivo, y me ha parecido muy original la manera que lo desarrollaron. La misma consiste básicamente en establecer el límite máximo a utilizar de RAM por el servicio en un valor bastante bajo obligandole al motor a liberar el recurso, y luego volviendo a establecer en su valor original. Son bien recibidos otros concejos y técnicas en los comentarios. (Continuar Leyendo sobre Reducir el uso de la memoria RAM de SQL Server en caliente sin reiniciar el servicio)

Las variables de sesión ya hemos visto como utilizar anteriormente en éste post, pero en ese momento sólo lo veíamos configurado con el método InProc que consume bastante memoria RAM del servidor. Hoy configuraremos para que la aplicación utilice SQL Server para administrar éstas variables.

Las ventajas y desventajas de cada modo de uso hace que sea ideal para casos específicos, en resumen, manejarlo con el método InProc hace que sea más rápida la lectura/escritura de las misma, pero otorga un alto consumo de memoria: si tenemos muchos objetos almacenado allí y más si tenemos una alta concurrencia. En cambio al almacenarlas (Continuar Leyendo sobre Configurar SQL Server para almacenar el estado de la sesión de ASP.NET)

Más de uno me mirará con una cara ¿De que hablas, Willis? preguntándose que es un particionamiento horizontal de tablas. Se le llama así cuando tenemos tablas que almacenan un conjunto demasiado grande de registros (en millones) y éste comienza a tener un bajo rendimiento, es entonces cuando se decide partir la tabla en tablas más pequeñas en cuanto a su almacenamiento de datos se refiere.

Para comprender completamente el concepto de Particionamiento Horizontal necesitaremos el conocimiento previo de herencia de tablas en éste motor, lo pueden leer aquí si lo desean.

Hace unos meses hablaba con un amigo y colega sobre sus tareas en una empresa de gran porte en donde tiene millones de filas creadas al día, el rubro es la telefonía celular y almacenan los mensajes de texto para luego trabajar con ellos, me mencionaban que iban partiendo sus tablas de manera manual separado en meses y el DBA (Continuar Leyendo sobre Particionamiento Horizontal de Tablas en PostgreSQL)

Hace unos días que vengo experimentando un poco con la publicidad en el blog, además de ir ajustando los reportes que me obtengo de Google Analytics. En el proceso me encontré con una información muy interesante en este blog y de tanto que me gusto lo quiero comentar aquí también.

Comencé a ver el porcetaje de rebote del blog y vi que era muy alto, pero no sabía que significaban realmente esos valores y me puse a investigar. Normalmente cuando los usuarios llegan a un sitio y se quedán por varios minutos, o comienzan a navegar por las distintas secciones del mismo, se considera que existe un porcentaje de rebote bajo, pero si el usuario llega y sale rápidamente se considera un porcentaje alto.

¿Esto quiere decir que el contenido del sitio no es interesante? realmente no aún, comparando con devtroce si un usuario llega buscando algún trozo de código especifico lo copia, lo usa y se va. (Continuar Leyendo sobre Afinar el porcentaje de rebote real de Google Analytics)

Los SubQuery’s o SubConsultas son herramientas poderosas si las sabemos usar, y son básicamente consultas anidadas en otras consultas la cual devuelve un conjunto de valores. Prácticamente un SubQuery puede ser utilizado en cualquier expresión y cláusula ya sean SELECT, FROM, WHERE, GROUP BY, HAVING, ORDER BY.

Como el tema de los SubQuery es bastante largo lo iré partiendo en pedazos agrupados por expresión (recomendación de Juan Cuevas), como lo ven en el título ahora veremos los SubQuerys aplicados en la cláusula FROM.

Ya sabemos que la cláusula FROM sirve para identificar las tablas de donde serán proveídos los datos a retornarse, como un SubQuery retorna un conjunto de valores también (Continuar Leyendo sobre SubQuery SQL: cláusula FROM)