Search This Blog

Showing posts with label technology. Show all posts
Showing posts with label technology. Show all posts

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

Fragmentación y desfragmentación de índices


Una de las tareas más comunes y necesarias durante el proceso de optimización y mantenimiento de las bases de datos es la desfragmentación de los índices, es así mismo quizá la tarea más olvidada por los administradores de bases de datos.
Los índices altamente fragmentados pueden afectar de manera negativa el rendimiento del motor de bases de datos e incluso causar que su aplicación no responda de la manera adecuada. 

Fragmentación: Proceso mediante el cual el motor de base de datos debido a las constantes tareas de Insert, Update y Delete, a medida que estas instrucciones se van ejecutando dentro de nuestra base de datos, la misma sufre un proceso de dispersión de los datos, más conocida como fragmentación. La fragmentación ocurre cuando los índices tienen páginas que se encuentran ordenadas de forma lógica, y basándose en la llave estos no coinciden con el orden físico dentro del archivo de datos.

La fragmentación se puede solucionar mediante 2 opciones, reorganizar y/o reconstruir los índices, para los índices particionados esta tarea se puede ejecutar tanto en el índice completo como en la partición del mismo.
Reconstrucción del índice (Rebuild): Este proceso elimina y crea nuevamente el índice, remueve la fragmentación y recupera espacio en disco compactando las páginas basándose en la configuración del fill factor o en el parámetro de la instrucción.

Reorganización del índice (Reorganize): Este proceso requiere menos recursos del sistema y realiza la desfragmentación al nivel de la hoja de la página, reorganizando a nivel físico las hojas para que coincidan con el orden lógico de las mismas, la reorganización también compacta las páginas de los índices, esta se da basándose en la configuración del fill factor.
Detección de la fragmentación de los indices
Lo primero es determinar que método de desfragmentación usar, para esta tarea se puede utilizar la función sys.dm_db_index_physical_stats, esta nos devuelve la fragmentación de un índice, de los índices en una tabla, de los índices en una base de datos  o de todos los índices en todas las bases de datos, de igual manera para los índices particionados, esta función nos devuelve el estado de cada una de las particiones asociadas al índice.

Columna
Descripción
avg_fragmentation_in_percent
Porcentaje de fragmentación lógica
fragment_count
Cantidad de fragmentos
avg_fragment_size_in_pages
Numero promedio de páginas en un fragmento de un índice.
  
Tenga en cuenta las siguientes recomendaciones para determinar si debe reorganizar o reconstruir su índice. 

Porcentaje de fragmentación
Instrucción a ejecutar
Entre 5% y 30%
ALTER INDEX REORGANIZE
Mayor al 30%
ALTER INDEX REBUILD

Consulta para determinar el porcentaje de fragmentación (En toda la base de datos)

WITH INDICES (BD, INDICETIPO, FRAGMENTACION, INDICE, TABLA)
AS (
SELECT DBS.NAME BASEDEDATOS, PS.INDEX_TYPE_DESC, PS.AVG_FRAGMENTATION_IN_PERCENT,
IND.NAME INDICE, TAB.NAME TABLA
FROM
SYS.DM_DB_INDEX_PHYSICAL_STATS (DB_ID(), NULL, NULL, NULL, NULL) PS
INNER JOIN SYS.DATABASES DBS
ON PS.DATABASE_ID = DBS.DATABASE_ID
INNER JOIN SYS.INDEXES IND
ON PS.OBJECT_ID = IND.OBJECT_ID
INNER JOIN SYS.TABLES TAB
ON TAB.OBJECT_ID = IND.OBJECT_ID
WHERE IND.NAME IS NOT NULL AND PS.INDEX_ID = IND.INDEX_ID
AND PS.AVG_FRAGMENTATION_IN_PERCENT > 0)
SELECT DISTINCT 
      CASE
      WHEN FRAGMENTACION > 5 AND FRAGMENTACION <= 30 THEN 'ALTER INDEX ' + INDICE + ' ON ' + TABLA + ' REORGANIZE'     
      WHEN FRAGMENTACION > 30 THEN 'ALTER INDEX ' + INDICE + ' ON ' + TABLA + ' REBUILD'
      END QUERY, FRAGMENTACION, BD, INDICE, TABLA
FROM (SELECT FRAGMENTACION, INDICE, TABLA, BD FROM INDICES
      WHERE FRAGMENTACION > 5) A
ORDER BY FRAGMENTACION DESC

Los índices pueden ser reconstruidos en línea o fuera de línea, la reorganización siempre se da en línea, para mantener niveles de disponibilidad similares a la de los índices reorganizados, la reconstrucción debe darse en línea y mediante la instrucción.
ALTER INDEX REBUILD WITH (ONLINE = ON)

Thursday, June 11, 2009

Comprimir o no comprimir, esa es la cuestion

Muchas personas preguntan acerca de las ventajas de comprimir, muchos quieren saber si deben o no deben comprimir sus tablas, saber con cuales ganan y con cuales no, saber si van a mejorar o si por el contrario, los algoritmos pueden jugar en su contra.

Bueno, dedique una tarde a determinar como hacer para que cualquier persona pueda saber si debe o no debe comprimir sus datos.

1. Determinemos cuanto espacio podriamos ahorrar en una tabla, para esto usaremos el procedimiento almacenado sp_estimate_data_compression_savings, con este vamos a determinar que ventajas tenemos al comprimir una tabla, para esto vamos a ejecutar el siguiente codigo

EXEC sp_estimate_data_compression_savings 
'Production', 
'TransactionHistory', 
null, null, 'ROW'


Aqui, sencillamente estamos estimando el mejoramiento que tendremos al comprimir la tabla TransactionHistory, del esquema Production.



image



Aqui lo que podemos leer es lo siguiente:



Por ejemplo, en el indice 1, podemos determinar que tenemos un tamano actual de 6352 KB, y podemos estimar que al comprimirlo, lograriamos un tamano de 4208 KB, que es una reduccion del 33,5%.



Ahora, podemos hacer esto una y otra vez, objeto por objeto, o podemos sentarnos unos minutos y escribir una consulta que nos permita ejecutar esto para todos los objetos, yo decidi hacerlo, y aqui lo tengo para ustedes.





   1: Create table ##tb ([object_name] varchar(500), 



   2: [schema_name] varchar(500),  



   3: [index_id] int, partition_number int,



   4: [size_with_current_compression_setting (KB)] bigint,



   5: [size_with_requested_compression_setting (KB)] bigint,



   6: [sample_size_with_current_compression_setting (KB)] bigint,



   7: [sample_size_with_requested_compression_setting (KB)] bigint)



   8: Declare @Esquema varchar(200), @Tabla varchar(200)



   9: declare Tabla_Cursor cursor for



  10: Select s.[name] Esquema, t.[name] Tabla  from sys.schemas s



  11: inner join sys.tables t on s.[schema_id] = t.[schema_id]



  12: Order by s.[name], t.[name]



  13: OPEN Tabla_Cursor



  14: Fetch next from Tabla_Cursor into @Esquema, @Tabla



  15: While @@FETCH_STATUS = 0



  16: Begin



  17:     insert ##tb 



  18:     exec sp_estimate_data_compression_savings 



  19:     @Esquema, @Tabla, NULL, NULL, @Tipo ;



  20:     Fetch next from Tabla_Cursor into @Esquema, @Tabla;



  21: End



  22: Close Tabla_Cursor



  23: Deallocate Tabla_Cursor



  24: select * From ##tb



  25: Drop table ##tb






Sin embargo debemos tener en cuenta que esto debe ser ejecutado bajo el contexto de cada base de datos.





Igualmente, senti la necesidad de hacer un reporte que nos permitiera hacer esto mucho mas rapido.



image



Aqui lo que podemos ver es una diferenciacion simple, de cuanto podriamos llegar a ahorrar en espacio comparando la compresion actual de su base de datos, versus la compresion seleccionada.



Si quieres descargar este reporte puedes dar clic aqui



Tuesday, June 9, 2009

Backups comprimidos en SQL Server 2008 – Cuanto me cuesta?

Este tema ha sonado bastante recientemente, y efectivamente, como seguramente muchos de ustedes habrán escuchado, SQL Server 2008 tiene la característica de poder tener los backups comprimidos, y hacerlo es muy fácil, vamos a ver aquí de que se trata:

De que se trata?

En realidad es muy sencillo, ahora con SQL Server 2008, tenemos la opción de determinar si queremos que nuestros backups estén o no estén comprimidos, hagamos un cálculo rápido para ver de qué se trata; hoy en día estamos pagando alrededor de 50 Centavos de Dólar por cada Giga (GB) de almacenamiento, es decir, si tenemos una base de datos de 2 GB, estaríamos pagando diariamente aproximadamente 1 Dólar por el hecho de tener ese Backup, muchas organizaciones no piensan en esto y consideran que no es un tema relevante, pero veámoslo de una forma mas traumática.

Pensemos en una base de datos de Un Terabyte 1 TB, esto es bastante común en una empresa de comunicaciones, ahora, calculemos entonces cuanto nos costaría tener esa base de datos.

1 TB = 1000 GB

1 GB = 0,5 USD

1 TB = 500 USD

Hasta aquí, todo normal, para una empresa de comunicaciones seguramente 500 USD no es una cantidad significativa.

Ahora vamos a implementar un sistema de backups muy simple, una copia full cada día (Recuerden que estas empresas funcionan segundo a segundo, así que uno por día es MUY poco)

1 Día = 500 USD (Costo de almacenamiento de la copia de seguridad de la base de datos)

1 Semana = 7 Días

1 Mes = 30 Días

Pensemos ahora que ellos solo deben mantener esta copia de seguridad por 2 meses, y pensemos también que estos medios pueden ser reutilizados 4 veces (Algo que sería un milagro, normalmente estos pueden ser utilizados una sola vez).

Estamos siendo muy optimistas.

60 Días = $ 30.000 USD

1 Unidad = 4 Copias

240 Días = $ 30.000 USD

1 Año = 360 Días (Para hacerlo más fácil)

3 Años = $ 135.000 USD

Bastante dinero no?, y recuerden, esto siendo optimistas, haciéndolo con recursos que prácticamente hoy no existen, ya que las copias de seguridad se supone que deben ser almacenados en un dispositivo, y este jamás ser reutilizado.

Ahora bien, si hacemos un calculo rapido de las ventajas de tener backups comprimidos, versus el tenerlos descomprimidos, sabremos rapidamente que nos conviene mas.

Esta caracteristica esta incluida de forma GRATUITA con Microsoft SQL Server 2008 Enterprise Edition.

LinkWithin

Related Posts Plugin for WordPress, Blogger...