Práctica No. 6.Particiones

Objetivo: Definir Tablas e índices con particiones, realizando una carga de datos.

SQL Server es compatible con la creación de particiones de tabla e índice. Los datos de tablas e índices con particiones se dividen en unidades que pueden propagarse por más de un grupo de archivos de la base de datos. Los datos se dividen en sentido horizontal, de forma que los grupos de filas se asignan a particiones individuales. Las particiones de un índice o una tabla deben encontrarse en la misma base de datos. La tabla o el índice se tratarán como una sola entidad lógica cuando se realicen consultas o actualizaciones en los datos. Las tablas e índices con particiones no están disponibles en todas las ediciones de Microsoft SQL Server. Para obtener una lista de características admitidas por las ediciones de SQL Server, vea Características compatibles con las ediciones de SQL Server 2014.

SQL Server 2014 admite hasta 15.000 particiones de forma predeterminada. En las versiones anteriores a SQL Server 2012, el número de particiones está limitado a 1.000 de forma predeterminada. En sistemas basados en x86, se puede crear una tabla o un índice con más de 1000 particiones pero no se admite.

Correlación com el programa de estudios

Ampliar las competencias dek futuro profesional de la computación. Considerando el amplio mercado de los productos

Microsoft.

Metodología

La creación de particiones de tablas o índices grandes puede tener las siguientes ventajas de administración y rendimiento.

Cuando SQL Server realiza una ordenación de los datos para operaciones de E/S, los ordena primero por partición. SQL Server tiene acceso a una unidad cada vez y esto podría reducir el rendimiento. Para mejorar el rendimiento de la ordenación de los datos, cree franjas de los archivos de datos de las particiones en más de un disco configurando una RAID. De este modo, aunque SQL Server siga ordenando los datos por partición, puede tener acceso a todas las unidades de cada partición al mismo tiempo.

Además, la partición permite mejorar el rendimiento habilitando la extensión de bloqueo en el nivel de partición y no en toda la tabla. Esto puede reducir la contención en la tabla por bloqueo.

Sugerencias didácticas

Instrucciones de rendimiento

El nuevo, mayor límite de 15.000 particiones afecta a la memoria, operaciones con particiones de índice, comandos DBCC, y consultas. Esta sección describe las implicaciones para el rendimiento de aumentar el número de particiones en 1.000 y proporciona soluciones según sea necesario. Con el límite en el número máximo de particiones ampliado a 15.000, puede almacenar los datos durante más tiempo. Sin embargo, debe conservar datos solo mientras sea necesario y mantener un equilibrio entre el rendimiento y el número de particiones.

Instrucciones y uso de la memoria

Se recomienda usar al menos 16 GB de RAM si un gran número de particiones están en uso. Si el sistema no tiene suficiente memoria, (DML) las instrucciones de lenguaje de manipulación de datos, (DDL) instrucciones de lenguaje de definición de datos y otras operaciones pueden generar errores debido a la memoria insuficiente. Los sistemas con 16 GB de RAM que funcionan con muchos procesos intensivos de memoria pueden quedarse sin memoria en operaciones que ejecutan en un gran número de particiones. Por consiguiente, cuanta más memoria se tenga por encima de 16 GB menor es la posibilidad de enfrentarse a problemas de rendimiento y de memoria.

Las limitaciones de memoria pueden afectar al rendimiento o capacidad de SQL Server para compilar un índice con particiones. Esto sucede especialmente cuando el índice no está alineado con su tabla base o no está alineado con su índice clúster si ya se ha aplicado un índice clúster a la tabla.

Operaciones de índices con particiones

Las limitaciones de memoria pueden afectar al rendimiento o capacidad de SQL Server para compilar un índice con particiones. Esto es especialmente así con índices no alineados. La creación y recompilación de índices no alineados en una tabla con más de 1.000 particiones es posible, pero no se admite. Si se hace, se puede degradar el rendimiento o consumir excesiva memoria durante estas operaciones.

Crear y recompilar índices alineados podría tardar mucho más tiempo en ejecutarse cuando el número de particiones aumenta. Se recomienda que no ejecute varios comandos de crear y recompilar índices al mismo tiempo, ya que quizás se enfrente a problemas de rendimiento y memoria.

Cuando SQL Server realiza la ordenación para compilar índices con particiones, primero compila una tabla de orden para cada partición. A continuación, compila las tablas de orden en el grupo de archivos respectivo de cada partición o en tempdb si se ha especificado la opción de índice SORT_IN_TEMPDB. Cada tabla de orden requiere una cantidad mínima de memoria para su compilación. Cuando crea un índice con particiones que está alineado con su tabla base, las tablas de orden se crean de una en una con menos memoria. Sin embargo, cuando crea un índice con particiones no alineado, las tablas de orden se crean al mismo tiempo. En consecuencia, debe haber disponible memoria suficiente para permitir la realización de estas ordenaciones simultáneas. Cuanto mayor es el número de particiones, mayor es la cantidad de memoria necesaria. El tamaño mínimo para cada tabla de orden y para cada partición es de 40 páginas y 8 kilobytes por página. Por ejemplo, un índice con particiones no alineado con 100 particiones necesita memoria suficiente para ordenar en serie 4.000 (40 * 100) páginas al mismo tiempo. Si esta memoria está disponible, la operación de creación será satisfactoria, aunque ello afectará negativamente al rendimiento. Si esta memoria no está disponible, se producirá un error durante la operación de creación. De forma alternativa, un índice con particiones alineado con 100 particiones solo necesita memoria suficiente para ordenar 40 páginas, ya que las ordenaciones no se realizan al mismo tiempo.

Tanto para los índices alineados como para los no alineados, el requisito de memoria puede ser mayor si SQL Server está aplicando grados de paralelismo a la operación de compilación en un equipo con varios procesadores. Esto es así porque cuanto mayores son los grados de paralelismo, mayor es también el requisito de memoria. Por ejemplo, si SQL Server establece los grados de paralelismo en 4, un índice no alineado con 100 particiones necesitará memoria suficiente para que cuatro procesadores puedan ordenar 4.000 páginas al mismo tiempo o 16.000 páginas. Si el índice con particiones está alineado, el requisito de memoria se reduce a cuatro procesadores que ordenan 40 páginas o 160 (4 * 40) páginas. Puede usar la opción de índice MAXDOP para reducir manualmente los grados de paralelismo.

Comandos DBCC

Con un número de particiones mayor, los comandos DBCC pueden tardar más tiempo en ejecutarse cuando el número de particiones aumenta.

Consultas

Las consultas en que se usa la eliminación de particiones podrían tener un rendimiento comparable o mejorado con un número de parti

ciones mayor. Las consultas que no usan eliminación de particiones podrían tardar más tiempo en ejecutarse cuando el número de particiones aumenta.

Por ejemplo, suponga que una tabla tiene 100 millones de filas y columnas A, B y C. En el escenario 1, la tabla se divide en 1.000 particiones en la columna A. En el escenario 2, la tabla se dividen en 10.000 particiones en la columna A. Una consulta en la tabla que contiene una filtrado de cláusula WHERE en la columna A realizará la eliminación de la partición y examinará una partición. La misma consulta puede ejecutarse con mayor rapidez en el escenario 2 al haber menos filas para examinar en una partición. Una consulta que tiene una cláusula de filtrado WHERE en la columna B examina todas las particiones. La consulta puede ejecutarse con mayor rapidez en el escenario 1 que en el escenario 2 ya que hay menos particiones para examinar.

Las consultas que usan operadores como TOP o MAX/MIN en columnas distintas de la columna de partición pueden experimentar un menor rendimiento con las particiones porque se deben evaluar todas las particiones.

Cambios de comportamiento en el cálculo de estadísticas durante operaciones con particiones de índice

A partir de SQL Server 2012, las estadísticas no se crean examinando todas las filas de la tabla cuando se crea o se vuelve a generar un índice con particiones. En su lugar, el optimizador de consultas usa el algoritmo de muestreo predeterminado para generar estadísticas. Después de actualizar una base de datos con índices con particiones, puede observar una diferencia en los datos del histograma para estos índices. Este cambio de comportamiento puede no afectar al rendimiento de las consultas. Para obtener estadísticas sobre índices con particiones examinando todas las filas de la tabla, Use CREATE STATISTICS o UPDATE STATISTICS con la cláusula FULLSCAN.

Material y equipo necesario

Cuebta de administrador

Bases de datos ejemplo

Reporte del alumno

Ejercicios de oracle (Pagina), SQL Server y MySqL

Preentarlos en el formato acostumbrado

¿Qué método dee particionamiento es más eficiente

Anexar el diagrama entidad relación correpondiente

Video tutorial con resultados

Conckusiones

Bibliografía preliminar

http://gherrerasqlserver.blogspot.mx/2013/05/particionar-tablas-en-5-pasos.html

http://social.technet.microsoft.com/wiki/contents/articles/13842.como-particionar-una-tabla-existente-es-es.aspx

http://blogs.technet.com/b/sql_pfe_latam/archive/2011/07/19/tablas-particionadas.aspx

(2007). Particionamiento en Oracle Database 11g. Informe Ejecutivo de Oracle

Partitioned Tables And Indexes. http://oracle-base.com/articles/8i/partitioned-tables-and-indexes.php



Anterior
Valid XHTML
home

Siguiente