Conceptos de tablas e índices con particiones
La partición facilita el uso de tablas e índices grandes, ya que permite administrar y tener acceso a subconjuntos de datos de forma rápida y eficaz, a la vez que mantiene la integridad de la colección de datos. Si se utilizan las particiones, una operación como la carga de datos desde un sistema OLTP a un sistema OLAP tarda sólo unos segundos, en lugar de los minutos y las horas que tardaba en versiones anteriores de SQL Server. Las operaciones de mantenimiento que se realizan en los subconjuntos de datos también se realizan de forma más eficaz porque estas operaciones sólo afectan a los datos necesarios, en lugar de a toda la tabla.
[!NOTA] Las tablas y los índices con particiones sólo se admiten en las ediciones Enterprise y Developer de Microsoft SQL Server 2005.
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. La tabla o el índice se tratarán como una sola entidad lógica cuando se realicen consultas o actualizaciones en los datos. Las particiones de un índice o una tabla deben encontrarse en la misma base de datos.
Las tablas y los índices con particiones admiten todas las propiedades y características asociadas con el diseño y la consulta de tablas e índices estándar, incluidas las restricciones, los valores predeterminados, los valores de identidad y marca de hora, así como los desencadenadores. Por tanto, si desea implementar una vista con particiones local en un servidor, puede interesarle implementar en su lugar una tabla con particiones.
La decisión acerca del uso de las particiones depende básicamente del tamaño actual o futuro de la tabla, la forma en que se utiliza y el rendimiento que presenta en las consultas de usuario y las operaciones de mantenimiento.
Por regla general, puede resultar adecuado crear particiones de una tabla grande si se cumplen las dos condiciones siguientes:
- La tabla contiene, o se espera que contenga, muchos datos que se utilizan de formas diferentes.
- Las consultas o las actualizaciones en la tabla no presentan el rendimiento que se esperaba o los costos de mantenimiento superan los períodos de mantenimiento predefinidos.
Por ejemplo, si los datos del mes actual se utilizan principalmente en operaciones INSERT, UPDATE y DELETE, y los de meses anteriores en consultas SELECT, la administración de la tabla sería más fácil si se crearan particiones por mes. La ventaja puede ser especialmente importante si las operaciones de mantenimiento periódicas sólo afectan a un subconjunto de los datos. Si la tabla no dispone de particiones, estas operaciones pueden consumir muchos recursos en un conjunto de datos completo. Con las particiones, las operaciones de mantenimiento como las regeneraciones de índice y las desfragmentaciones se pueden realizar en los datos de sólo escritura de un único mes; por ejemplo, mientras que los datos de sólo lectura siguen disponibles para el acceso en línea.
Para ampliar este ejemplo, supongamos que desea mover los datos de sólo lectura de un mes de esta tabla a una tabla de almacén de datos para su análisis. Con las particiones, se pueden separar rápidamente los subconjuntos de datos en áreas de ensayo para el mantenimiento sin conexión y posteriormente agregarlos como particiones a tablas con particiones existentes, siempre que dichas tablas se encuentren en la misma instancia de base de datos. Las operaciones de este tipo pueden tardar segundos, en lugar de los minutos o las horas que tardaban en versiones anteriores.
Por último, la creación de particiones en una tabla o un índice puede mejorar el rendimiento de las consultas si las particiones se diseñan correctamente, basándose en los tipos de consultas que se ejecutan con más frecuencia y en la configuración del hardware. Para obtener más información, vea Diseñar particiones para mejorar el rendimiento de las consultas.
Para consultar un ejemplo sobre la forma de aplicar una solución de particiones en una base de datos real, dispone de un escenario de partición que puede implementar en la base de datos de ejemplo AdventureWorks. Este escenario se explica en Crear particiones en la base de datos de ejemplo AdventureWorks.
Arquitectura de las particiones
En SQL Server 2005, se considera que todas las tablas e índices de una base de datos disponen de particiones, incluso si se componen de una sola partición. Básicamente, las particiones conforman la unidad básica de organización en la arquitectura física de tablas e índices. Esto significa que la arquitectura lógica y física de las tablas y los índices compuestos por varias particiones es igual a la de tablas e índices con una única partición. Para obtener más información, vea Organización de tablas e índices.
Vea también
Conceptos
Diseñar tablas e índices con particiones