SCRUM - Una muy buena herramienta

A medida que van creciendo los requerimientos de desarrollo, aumenta el poder asignar tareas, crear equipos, ver avances y responsables. A veces se hace tedioso si no contamos con una buena herramienta. Para dichos controles, existen varios metodos entre ellos el SCRUM, y existe, y que bueno a mi parecer, una pagina web que nos facilita esta tarea:

https://www.targetprocess.com

Esta página tiene la modalidad de que puedes accesar de forma gratuita y adicionar el equipo de trabajo.

Puedes determinar a un usario como Desarrollador y a otro como Ingeniero de Control de Calidad
es tan sencillo como arrastrar y soltar para indicar el avance de las tareas. En fin es una buena herramienta que incluso funciona con IOS y Android.

Muy recomendado.

este es el canal en youtube (ingles) para ver su funcionamiento:
https://www.youtube.com/user/TargetProcess

Optimización Automática: Desfragmentación de Índices SQL 2005/2008

Por Javier Loria

Cuando en una base de datos relacional sobre una tabla se hacen operaciones de inserción, borrado y actualización de columnas es natural que se produzca fragmentación lógica de índices. Una de las tareas del DBA es realizar tareas para mantener estos niveles de fragmentación bajos. La forma nativa de SQL 2005 y SQL 2008 de desfragmentar índices es por medio de planes de mantenimiento de base de datos. Pero deber recordarse varias cosas:

1. En general las actividades de fragmentación de índices participan en transacciones y pueden bloquear durante mucho tiempo páginas y tablas completas, si no se tiene cuidado al seleccionar diferentes opciones. La opción ONLINE, disponible solo en la versión corporativa de SQL, permite hacer operaciones de desfragmentación sin bloquear las tablas.
2. El modo de recuperación de la base de datos puede afectar el desempeño de la desfragmentación. El ALTER INDEX REBUILD y DBCC DBREINDEX son transacciones mínimamente registradas en la bitácora de transacciones cuando el modo de recuperación de la BD es Bulk-logged o Simple. El ALTER INDEX REORGANIZE y el DBCC INDEXDEFRAG son siempre transacciones registradas completamente en la bitácora de transacciones.
3. El asistente de planes de mantenimiento ofrece dos alternativas:
   1. REORGANIZE (Reorganizar): Esta opción emplea una tarea que genera ALTER INDEX REORGANIZE para todas las tablas de una base de datos o para una lista de tablas seleccionadas.
   2. REBUILD (Reconstruir): genera un ALTER INDEX REBUILD para todas las tablas de una base de datos o para una lista de tablas seleccionadas.
   La diferencia entre un REORGANIZE y un REBUILD es que el REORGANIZE desfragmenta los niveles hoja del índice, mientras que el REBUILD desfragmenta todos los niveles del índice.
4. Realizar tareas de mantenimiento sobre todos los índices con una plan de mantenimiento es una tarea que puede tomar mucho tiempo y no ser aceptable por dos razones:
   1. Llena el transacción log.
   2. Bloquea una cantidad importante de recursos del servidor, durante una ventana grande de tiempo.

El código que sigue a continuación puede ayudar al mantenimiento automatizado de índices de una BD relacional que cumplan con las siguientes condiciones:

1. BD OLTP, mediana o altamente normalizada.
2. Tamaño entre 2 y 100 Gb.
3. Tablas: 500 a 10,000.
4. Puede ser en servidores 24×7.

La estrategia es usar el código para programar 2 jobs que desfragmenten los índices:

1. Job de Matenimiento Índices Medianos: (1 vez cada hora).
   1. 10 índices medianos: EXEC dbo.DefragmentaIndices ‘Medianos’
2. Mantenimiento Diario: (1 vez cada día, en horarios de menos ocupación del servidor)
   1. 10 índices grandes: EXEC dbo.DefragmentaIndices ‘Grandes’
   2. 100 índices pequeños: EXEC dbo.DefragmentaIndices ‘Pequenos’

Para escribir el código conté con la ayuda de: Eladio Rincón, Miguel Egea y Enrique Catalá.
CREATE FUNCTION FilteredIndexFragmentation(
     @DatabaseID                INT
    , @ObjectID                    INT
    , @IndexID                        INT
    , @PartitionNumber        INT=NULL
    , @AverageFragmentation INT =0
    , @FragmentCount        BIGINT =0)
— Author:                         Javier Loria, Solid Quality Mentors
— Create date:                    5/Dic/2008
— Description:                    Funcion que lista los indices con un porcentaje de fragmentacion LOGICA mayor al indicado,
— y con una cantidad mayor de fragmentos.
— Encapsula dm_db_index_physical_stats., se requiere para poder hacer CROSS APPLY.
— No reporta fragmentacion de tablas sin indices, indices XML o Geograficos.
— Emplea el modo limitado ‘LIMITED’, por el alto costo y mal desempeno del modo ‘DETAILED’
RETURNS @IndexStats TABLE(
     DatabaseID                    SMALLINT
    , ObjectID                        INT
    , IndexID                            INT
    , PartitionNumber            INT
    , IndexDepth                    TINYINT
    , FragmentationRate        FLOAT
    , FragmentCount            BIGINT
    , AverageFragmentSize FLOAT
    , PageCount                    BIGINT)
BEGIN
    INSERT INTO @IndexStats(DatabaseID, ObjectID, IndexID, PartitionNumber, IndexDepth,FragmentationRate
        , FragmentCount, AverageFragmentSize, PageCount)
    SELECT database_id, object_id, index_id, partition_number,
         index_depth, avg_fragmentation_in_percent, fragment_count, avg_fragment_size_in_pages, page_count
    FROM sys.dm_db_index_physical_stats (@DatabaseID, @ObjectID, @IndexID, @PartitionNumber, ‘LIMITED’ )
    WHERE index_type_desc IN(‘CLUSTERED INDEX’, ‘NONCLUSTERED INDEX’)
    AND avg_fragmentation_in_percent > @AverageFragmentation
    AND fragment_count>@FragmentCount
RETURN
END
GO

CREATE PROCEDURE dbo.DefragmentaIndices(
— Author:                             Javier Loria, Solid Quality Mentors
— Create date:                    5/Dic/2008
— Description:                    Procedimiento que defragmenta indices, de una base de datos, de acuerdo al tamaño del indices.
— Indices Grandes:         10 Indices de cualquier tamaño, con mas de 30% de Fragmentacion y 10 o más segmentos
— Indices Medianos:        10 Indices entre 8192 y 32 páginas, mas del 20% de Fragmentacion y 3 o más segmentos
— Indices Pequenos: 100 Indices entre 256 y 32 páginas, , mas del 20% de Fragmentacion y 3 o más segmentos
— Parametros:                    @Tipo= Grandes, Medianos y Pequenos. Default=Grandes
    @Tipo    VARCHAR(10)=‘Grandes’        — Medianos, Pequenos
)
AS
DECLARE @db_id         INT;
DECLARE @NumPages     BIGINT;
DECLARE @NumIndexes INT;

DECLARE @Comando NVARCHAR(MAX);
DECLARE @DB INT
SET NOCOUNT ON;
SET @DB=DB_ID()        –Requerido por modo de compatibilidad 80.

IF (@Tipo NOT IN(‘Grandes’, ‘Medianos’, ‘Pequenos’))
    BEGIN
    RAISERROR(‘Parametro @Tipo Invalido, use: Grandes, Medianos o Pequenos’, 16,1);
    RETURN;
    END
SET @db_id = DB_ID(N’Adam’);
SET @Comando=”;

IF @Tipo=‘Grandes’
    BEGIN
    — Reindexa las 10 mas grandes sin importar el tamano
    SELECT TOP 10 @Comando=@Comando+CHAR(13)+CHAR(10)+‘ALTER INDEX ‘
        + Indexes.Name
        +‘ ON ‘+OBJECT_NAME(ObjectID)+‘ REBUILD;’
    FROM FilteredIndexFragmentation(@DB, NULL, NULL, NULL, 30,10) AS FIF
    JOIN SYS.INDEXES AS Indexes
        ON INDEXES.OBJECT_ID=ObjectID
            AND INDEXES.INDEX_ID=IndexID
    ORDER BY (IndexDepth*IndexDepth*FragmentationRate*FragmentCount/100) DESC
    END
ELSE
    BEGIN
    — Reindexa las 10 si es Medianos, 50 si es Pequenos
    SELECT TOP (CASE WHEN @Tipo=‘Medianos’ THEN 10 ELSE 50 END)
        @Comando=@Comando+CHAR(13)+CHAR(10)+‘ALTER INDEX ‘
        + IndexPages.Name
        +‘ ON ‘+OBJECT_NAME(ObjectID)+‘ REBUILD;’
    FROM (SELECT indexes.object_id
                , indexes.index_id
                , Indexes.Name
                , sum(allocation_units.total_pages) as totalPages
            FROM sys.indexes AS indexes
            JOIN sys.partitions AS partitions
            ON indexes.object_id = partitions.object_id
                    and indexes.index_id = partitions.index_id
            JOIN sys.allocation_units AS allocation_units
            ON partitions.partition_id = allocation_units.container_id
            WHERE indexes.index_id >0
             AND allocation_units.total_pages>0
            GROUP BY indexes.object_id, indexes.index_id, Indexes.Name
            HAVING sum(allocation_units.total_pages) BETWEEN 32 AND
                (CASE WHEN @Tipo=‘Medianos’ THEN 8192 ELSE 256 END)        
— Medianos si tienen menos de 8192 paginas, Pequenos si tienen menos de 256 paginas
            ) AS IndexPages
— No se emplea el CROSS APPLY por compatibilidad con nivel de compatibilidad 80 (SQL 2000),
— es posible que tenga un importante impacto en desempeno usar el CROSS APPLY.
— se recomienda usar CROSS APPLY para compatibilidad 90 o 100.
—    CROSS APPLY FilteredIndexFragmentation(@DB, IndexPages.object_id, IndexPages.index_id, NULL, 20,3) AS FIF
    JOIN FilteredIndexFragmentation(@DB, NULL, NULL, NULL, 20,3) AS FIF
    ON IndexPages.object_id=FIF.ObjectID
        AND IndexPages.index_id=FIF.IndexID
    — La columna IndexDepth esta deliberadamente 2 veces, para dar prioridad a indices mas profundos.
    ORDER BY (IndexDepth*IndexDepth*FragmentationRate*FragmentCount/100) DESC

    END
EXEC sp_executesql @Comando
GO 


Articulo de Javier Loria
Fuente:   Javier Loria SolidQ

Cursos Gratis Diplomados

Me encontre una pagina que ofrece cursos gratis, de varios tipos, yo me centre en el area de IT, y explica por medio de videos los conceptos fundamentales del curso elegigo.

Al final de cada curso puedes imprimir un diploma de participación. Tambien cuenta con una bolsa de trabajo.

Es muy interesante, se las recomiendo:

https://capacitateparaelempleo.org/

Solo tienes que registrarte con tu correo electrónico,luego elegir el plan de cursos y listo, a iniciar.

Espero le puedan sacar el provecho.

DBA - Admin

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. 

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)

Fuente: Microsoft Tech Net

SELECT INTO vs INSERT INTO on Columnstore

By Ramya Makam, 2016/08/05 (first published: 2015/06/09)

Introduction

There were many enhancements in SQL Server 2014 and one amongst them is the fact that SELECT INTO now operates with parallelism. How does that help us if we need to use it on tables with clustered columnstore indexes? This article compares SELECT INTO and INSERT INTO under different scenarios, and the best approach preferred.

Explanation

I considered a table, test_source, containing 50 million rows for my tests. The space used by this table without any index on it is 23.8GB. A screenshot of the space used is shown below.

Scenario 1

Let us consider the following scenario where the source table, test_source, has a clustered columnstore index on it, and the destination table, test_dest, requires a clustered columnstore index to be created on it. This is shown in the table below.

Source table has cci index on it?	Destination table requires cci index on it?
yes	yes

First, I used “SELECT INTO” from test_source to test_dest. I then created a clustered columnstore index on the destination table. The observations are shown below. First is the output of the SELECT INTO statement:

Let’s see the space used by the table, “test_dest”.

The datafile has grown to 23.8 GB and log file has grown to 555MB.
I then created a clustered columnstore index on the destination table “test_dest” and observations are below.

Space used by the table test_dest is 3 GB

The datafile has grown to 26.8 GB and logfile has grown to 555 MB. The total time taken for the SELECT INTO + Create columnstore is 22 minutes.
Now let us consider the following scenario where we create the table first, then create clustered columnstore index and insert the data. The observations are shown below.

The space used by the table “test_dest” is shown below

The datafile has grown to 3.01 GB and log file has grown to 132 MB. The space used by the database now is 3.1 GB

The total time taken for creating the table, clustered columnstore index and inserting the data is 30 minutes. 
When comparing these two scenarios, we can easily notice that SELECT INTO is faster than INSERT INTO. However, SELECT INTO consumes more space. INSERT INTO is a little bit slower but doesn’t cause space issues, even when the datafile has less free space. Having free space of 3.01 GB is enough for the INSERT INTO operation whereas SELECT INTO requires 23.8 GB for the operation to complete.

Scenario 2

Let’s consider the following scenario where source table “test_source” has clustered columnstore index on it and destination table “test_dest” doesn’t require clustered columnstore index to be created on it.

source table has cci index on it ?	Destination table requires cci index on it ?
yes	no

First, I used SELECT INTO from source table to destination table and then created clustered columnstore index on the destination table. The observations are shown below.
This is the output of the SELECT INTO statement:

Let’s see the space used by the table, test_dest.

The datafile has grown to 23.8 GB and log file has grown to 555MB. The total time taken for SELECT INTO is 17 minutes.
Now let’s consider the following scenario where we create the table first and insert the data. The observations are shown below.

The space used by the table, test_dest, is shown below

The datafile has grown to 23.8 GB GB and log file has grown to 43.5 GB. The space used by the database is now 67.3 GB

The total time taken for creating the table and inserting the data is 25 minutes.
When comparing these two scenarios, we notice that SELECT INTO is faster and consumes less log size than inserting the data using INSERT INTO. SELECT INTO is faster because it operates in parallel and is a bulk operation from behind, whereas INSERT INTO is a single threaded operation and consumes more log space when destination table is a rowstore.

Scenario 3

Let us consider the following scenario where the source table doesn’t have a clustered columnstore index on it and the destination table requires a clustered columnstore index to be created on it.

source table has cci index on it ?	Destination table requires cci index on it ?
no	yes

First, I used SELECT INTO from the source table to the destination table and then created a clustered columnstore index on the destination table. The observations are mentioned below. This is the output of select into statement

Let’s see the space used by the table, test_dest.

The datafile has grown to 23.8 GB and log file has grown to 555MB.
I then created a clustered columnstore index on the destination table, and the observations are below.

Space used by the table test_dest is 3 GB.

The datafile has grown to 26.8 GB and the log file has grown to 555 MB. The total time taken for SELECT INTO + Create columnstore is 22 minutes.
Now let’s consider the following scenario where we create the table first, then create clustered columnstore index and insert the data. The observations are shown below.

The space used by the table, test_dest, is shown below.

The datafile has grown to 2.98 GB and log file has grown to 109 MB. The space used by the database is now 3.1 GB.

The total time taken for creating the table, creating the clustered columnstore index, and inserting the data is 28 minutes.
When comparing these two scenarios, we can easily notice that SELECT INTO is faster than INSERT INTO. However, SELECT INTO consumes more space. INSERT INTO is a little bit slower but doesn’t cause space issue even when the datafile has less free space. Free space of 3.01 GB is enough for the INSERT INTO operation whereas SELECT INTO requires 23.8 GB for the operation to complete.
Below is the comparison of all the scenarios discussed in this article.

Conclusion

We can use either of the approaches among “SELECT INTO” and “INSERT INTO” for performing a table copy. When there are no space issues and we need the operation to complete faster, SELECT INTO is preferred. When there are space issues, INSERT INTO is preferred because operation might be slow but definitely succeeds.
Hope my article was helpful to you.


Fuente: www.sqlservercentral.com