Search This Blog

Wednesday, September 27, 2017

El algoritmo de llenado proporcional (Proportional fill)

En una reunión fuera de lo laboral me hicieron la siguiente pregunta:

¿Si yo pongo más archivos a mi base de datos, va a funcionar mejor?  o me da lo mismo?

Bien, la respuesta es relativa, ahora, de entrada, podemos decir que el rendimiento se va a mejorar, no sabemos a ciencia cierta y con tan poca información cuanto vaya a mejorar, pero de que mejora mejora, sea un 1%, pero eso es mejora al fin y al cabo.

El paso a seguir es entender cómo funciona el algoritmo de llenado proporcional (Proportional fill) que usa SQL Server.

El algoritmo de llenado proporcional en SQL Server se encarga básicamente de distribuir la carga a través de los diferentes archivos de datos que tenga un filegroup, como regla básica, la carga se va hacia el archivo de datos que mayor espacio disponible tenga.

Funciona mediante Round-Robin, de esta forma el algoritmo intenta ser lo mas equitativo posible en términos de carga en los archivos, sin embargo, esto trae otro dolor de cabeza, ¿Todos los discos de mi maquina tienen el mismo rendimiento esperado en términos de IOPs?, de ser así, pues no hay problema, pero de no ser así (Que es como seguramente ocurre), entonces vienen los problemas, se debe tener en cuenta que el rendimiento de mi base de datos entonces dependerá de mi componente mas lento, pero bueno, para seguir mas a fondo, veamos entonces:

¿Como saber cuánto espacio disponible tengo en cada archivo de datos?

SQL Server cuenta con la función FileProperty, esta función recibe como parámetros el nombre del archivo y la propiedad que se desea obtener, para este caso utilizamos la opción SpaceUsed, esta nos devuelve la información en términos de la cantidad de paginas en el archivo, siendo asi, debemos tener en cuenta que una pagina en SQL Server tiene un tamaño de 8KB, por ende debemos multiplicar este dato por 8 para obtener el tamaño en KB.

SELECT (FILEPROPERTY('AdventureWorks2012_Data', 'SpaceUsed') * 8)/1024 [Espacio en MB]

De igual manera utilizamos la tabla del sistema sys.master_files, allí tenemos cada archivo de datos y de log dentro de la base de datos, allí encontramos el tamaño del archivo igualmente en términos de paginas.

select name,
CAST(FILEPROPERTY(name, 'SpaceUsed') AS float) [Paginas],
size * 8 [Tamano KB],
CAST(FILEPROPERTY(name, 'SpaceUsed') AS float) * 8 [Usado en KB],
(size * 8) - (CAST(FILEPROPERTY(name, 'SpaceUsed') AS float) * 8) [Disponible en KB]
from sys.master_files
where type = 0
and database_id = db_id()

Tuesday, January 21, 2014

Bloqueo automatico de cuentas en SQL Server por numero de intentos

Algunas personas me han preguntado sobre la posibilidad de bloquear las cuentas de SQL Server cuando los usuarios fallen demasiadas veces al intentar autenticarse, aquí la solución aprovechando las características de directorio activo.


Friday, October 18, 2013

Ejecutar múltiples archivos SQL

Durante el Pass Summit en Charlotte, charlando con mi amigo Guillermo Taylor que por cierto les recomiendo leer su blog, hablábamos sobre la necesidad de ejecutar aproximadamente 4000 archivos SQL y cómo hacerlo rápidamente, bueno, durante esas charlas en los intermedios de más charlas llegamos a la conclusión de hacerlo utilizando PowerShell.

Ahora, imaginen un archivo .TXT con las siguientes características

C:\Queries\Query1.sql
D:\Consultas\Consulta1.sql
P:\MoreQueries\Query2.sql
P:\Consultas2\Consulta.sql



Bien, como pueden ver, el archivo contiene múltiples ubicaciones, bien, podríamos haberlo hecho utilizando SSIS (Como hacerlo con SSIS), pero solo para poner en practica nuestros skills con PowerShell decidimos hacerlo allí.

 

$archivo = "C:\ArchivosSQL\test.txt"
$entradas = gc $archivo
foreach ($entrada in $entradas)
{
    SQLCMD -S <SERVIDOR> -U <USUARIO> -P <PASSWORD> -d <BASE DE DATOS> -i $entrada
}




Enjoy it from the #Summit13 at #SQLPass

Tuesday, August 20, 2013

Antes y después del Merge – Upsert SQL Server

Hace poco tiempo un cliente me comentaba sobre la necesidad de ejecutar comandos de tipo UPSERT, típicamente este proceso lo venía haciendo de forma manual, hacia una revisión uno a uno de los campos y luego mediante estructuras en TSQL hacia la carga o la actualización a su base de datos, por eso me dispuse a escribir este post.

Desde la versión 2008 de Microsoft SQL Server, contamos con una nueva forma de actualizar o insertar datos a una tabla, este comando nos permite ir un paso más allá y en una sola transacción efectuar todo el proceso, de golpe y sin mayores complicaciones.

Ver todo el post en:

Thursday, January 31, 2013

Como determinar que puerto esta utilizando SQL Server 2012 Analysis Services

Un inconveniente común ahora entre muchos clientes que han implementado SQL Server Analysis Services en su versión 2012, es el cambio dinámico de puertos, típicamente estábamos acostumbrados a tener un puerto fijo en SSAS en versiones anteriores del producto, a partir de SQL Server 2012 y específicamente hablando de implementaciones de SSAS Tabular Mode, nos encontramos con puertos dinámicos, de esta forma, si el cliente reinicia su servidor o reinicia los servicios, el puerto cambiara dinámicamente, muchas aplicaciones usan queries a RPC para determinar que puerto esta utilizando un servicio y de esa forma dinámicamente determinar a que puerto debe conectarse, como es el caso de SQL Server Management Studio y que redunda en la razón por la cual muchos no detectamos esto hasta tanto alguien mas intenta ingresar utilizando opciones diferentes como por ejemplo PowerView desde Microsoft SharePoint.

Con el fin de determinar que puerto esta utilizando SQL Server Analysis Services 2012 después de un reinicio, utilizaremos el command prompt y un par de líneas de código que retornaran la información deseada. (Ver todo el articulo)

Friday, October 5, 2012

Como particionar una tabla existente


Una de las tareas más deseadas hoy en día por muchos administradores de bases de datos, es el particionar sus tablas, una de las grandes ventajas del particionamiento de tablas en SQL Server, es la capacidad de distribuir la carga física en múltiples discos duros, por ende, existen más partes mecánicas ejecutando una sola tarea.
Sin embargo, gran parte de estas bases de datos existen desde hace mucho tiempo, por lo que no se encuentran particionadas en su gran mayoría, además de estar soportando actualmente aplicaciones de negocio, debido a esto... (Ver todo el articulo)

Thursday, October 4, 2012

Como especificar el fill factor en un índice


La opción de fill factor permite el afinamiento del rendimiento y almacenamiento de los índices, cuando un índice es creado o reconstruido, el fill factor determina el porcentaje de espacio a nivel de la hoja de cada página que será llenada con datos; reservando el espacio restante en cada página como espacio libre y disponible para futuro crecimiento.
Ejemplo
Si tenemos un índice con un fill factor de 80, esto significa que el 20% de la página será reservado para el momento en que se agreguen datos que deban ser guardados en ese espacio.
Lleno
Lleno
Lleno
Lleno
Lleno
Lleno
Lleno
Lleno
Libre
Libre
 
El fill factor es un número que va de 1 a 100, a nivel de servidor el valor predeterminado es 0, esto significa que las paginas serán llenadas en su totalidad – El valor 0 y 100 significan lo mismo para el fill factor –

Consideraciones para temas de rendimiento

Page splits (Contador: \SQLServer:Access Methods\Page Splits/sec)

Elegir correctamente el fill factor para los índices puede reducir notablemente los page splits, aprovisionando suficiente espacio para la expansión de los índices a medida que más datos sean agregados a la tabla; cuando una fila es agregada a una página de índice que se encuentra llena, el motor mueve aproximadamente la mitad de las filas a una nueva página con el fin de abrirle espacio a la nueva fila; el proceso de reorganización sobre las paginas es conocido como page split, este proceso abre espacio para nuevas filas, pero puede tomar tiempo además de ser costosa a nivel de recursos de máquina, además, puede causar fragmentación, lo que aumenta las operaciones de I/O.
Cuando ocurren operaciones de tipo page split de forma frecuente, se debe considerar la reconstrucción del índice (ALTER INDEX REBUILD) utilizando un valor diferente de fill factor para redistribuir los datos; para más información vea el articulo fragmentación y desfragmentación de índices.
 

Tener en cuenta para determinar el fill factor

Un valor para el fill factor diferente al 100%, es decir distinto de 0 y de 100, puede ser positivo para el rendimiento de la base de datos siempre y cuando la información que se va agregando a la tabla se distribuya sobre la misma; sin embargo, si la información que se va insertando a la tabla siempre va al final de la misma, los espacios vacíos nunca serán llenados ni aprovechados, por ejemplo, si estamos agregando información con una columna de tipo IDENTITY y que esta corresponde a la llave de la tabla, está siempre será incremental y las filas del índice serán agregadas al final del índice.
Si las filas actuales serán actualizadas con datos que aumenten el tamaño de las filas, es recomendable utilizar un fill factor menor a 100, estos bytes extra en cada página ayudaran a minimizar los page splits causados por el crecimiento del tamaño de fila.

LinkWithin

Related Posts Plugin for WordPress, Blogger...