Problema con tablas particionadas

15/12/2004 - 16:25 por e.lorenzo | Informe spam
Hola a todos,

tenemos una aplicación que, por el volumen de información que maneja, nos
obliga a crear particiones por meses en 5 tablas del modelo. De esta
forma, mantendremos un histórico de 12 meses que iremos rotando. La idea
no es particionar para poder ejecutar las consultas en paralelo, sino por
facilitar el borrado y mantenimiento.

Cuando empezamos a analizar cómo crear estas particiones en SQL SERVER (la
aplicación también corre con Oracle y ahí hemos podido implementarlas sin
problemas), empezó nuestro "calvario".

Investigando, descubrimos que debíamos crear 12 tablas por cada una de las
que deseamos particionar y, en cada una de las 12, añadir una CHECK que
indique qué mes es el que contiene. A continuación, se crea una vista cuya
definición es un UNION ALL de cada una de las 12 tablas. Hasta aquí bien.

El problema es que una de las 5 tablas que deseamos particionar no tiene
clave primaria. Las otras cuatro sí la tienen y, además, el campo por el
que particionamos pertenece a ella.

La tabla no tiene clave primaria, porque intervienen 22 campos y no es
relevante, al controlar nosotros las inserciones. Tan sólo creamos dos
índices no únicos para optimizar las consultas que se realizan sobre ella.

Al ir a crear una partición, en SQL Server te exige que el campo sobre el
que indicas la condición forme parte de la clave primaria. Por tanto, como
no es viable crear la clave primaria con 22 campos (aparte de que el
límite son 15, el índice ocupa más que la tabla) y no queremos crear un
campo que guarde el valor de la concatenación de todos, nos planteamos
crear una PK con la fecha y un secuencial (IDENTITY). Pero nos encontramos
que en tablas particionadas no se permite usar esta funcionalidad.

Decidimos abordar el problema con un trigger que informara este valor
secuencial y nos permitiera simular la PK, pero el problema es que las
inserciones se hacen mediante INSERT...SELECT (con más de un registro) y
no éramos capaces de que le asignara un número diferente a cada registro,
sino el mismo a cada uno de los obtenidos en el SELECT.

¿Nos puede indicar alguien si hay alguna forma más sencilla de gestionar
las particiones o, si hasta ahora no hemos hecho nada mal, cómo podemos
crear una clave primaria "en tiempo de ejecución" con un INSERT..SELECT?
Por ejemplo, algo similar a la función ROWNUM de Oracle concatenada con un
timestamp. ¿Hay algo equivalente en SQL SERVER?

Contar con el agravante de que tenemos una aplicación ya rodada y con dos
gestores y queremos tratar de tener que montar un lío tremendo sólo por
SQL Server.

Muchas gracias por anticipado.

Un saludo

Preguntas similare

Leer las respuestas

#6 e.lorenzo
15/12/2004 - 18:19 | Informe spam
La cuestión es que algunos clientes no tienen grandes máquinas (es una
aplicación departamental) con picos de uso durante el mes.

Aún así, algunos clientes nos han pedido específicamente gestionarlo con
particiones y, por tanto, hemos de resolverlo.

Gracias de todas formas
Respuesta Responder a este mensaje
#7 Maxi
15/12/2004 - 18:26 | Informe spam
Hola, te explicas a la perfeccion, el tema es que a mi criterio no es
recomendado hacer las cosas asi.

Porque no armar las vistas indexadas y un SP que las llame? en la aplicacion
no deberias escribir sentencias SQL bajo ningun concepto te diria :(


Salu2
Maxi


"Quique" escribió en el mensaje
news:%

No hay nada que perdonarte, al contrario.

Entiendo que los delete los realizaría por tramos y no me tostaría la
máquina, pero aún así, tendré que recomponer la tabla y los índices, pues
quedarían muy "perjudicados".

La cuestión es que tenemos un problema añadido. Las consultas de SQL
(tanto las de inserción como las de lectura) se construyen con un motor de
SQL que hemos desarrollado y éste incorpora el nombre de la tabla,
llamémosla X. En caso de que hiciera las particiones, la vista es la que
se denominaría X.

Por tanto, no podría crearme 12 vistas y seleccionar en tiempo de
ejecución a cuál debo consultar. Tengo una SQL "fija" a la que le añado el
filtro de mes.

No sé si me explico bien y alcanzáis a ver el problema.

Gracias de todas formas.

Un saludo

Respuesta Responder a este mensaje
#8 e.lorenzo
15/12/2004 - 20:56 | Informe spam
Hemos hecho una prueba usando el comando NEWID() para generar un valor
diferente en cada registro del INSERT..SELECT y nos ha funcionado
correctamente la inserción en la vista.

Con esto hemos conseguido simular una clave primaria y ha permitido usar
las particiones.

Espero que no nos surja ningún contratiempo más.

Gracias a todos por vuestra ayuda.

Un saludo
Respuesta Responder a este mensaje
#9 Salvador Ramos
16/12/2004 - 11:26 | Informe spam
Me alegro que lo hayas solucionado.

Por si te sirve de ayuda, te comento que la version 2005 llevará bastantes
mejoras en el tema. En ella podrás utilizar "partitioning", puedes ver
alguna información en el webcast que se celebró ayer sobre alta
disponibilidad (en breve estará publicado en technet).

Un saludo
Salvador Ramos
Murcia - España
[Microsoft MVP SQL Server]
www.helpdna.net
¿Te interesa participar en las reuniones
del grupo de Usuarios de SQL-Server y .NET
Se harán en levante de España, (Alicante o Murcia)?

"Quique" escribió en el mensaje
news:

Hemos hecho una prueba usando el comando NEWID() para generar un valor
diferente en cada registro del INSERT..SELECT y nos ha funcionado
correctamente la inserción en la vista.

Con esto hemos conseguido simular una clave primaria y ha permitido usar
las particiones.

Espero que no nos surja ningún contratiempo más.

Gracias a todos por vuestra ayuda.

Un saludo

Respuesta Responder a este mensaje
#10 e.lorenzo
16/12/2004 - 13:36 | Informe spam
La verdad es que la solución nos obliga a hacer cambios importantes que
queríamos haber evitado, pero si es lo único que hay, pues a aguantarse.

Espero que este tema lo tengan más trabajado en la nueva versión, porque
esto parece un castigo... ;)

Muchas gracias y un saludo
email Siga el debate Respuesta Responder a este mensaje
Ads by Google
Help Hacer una pregunta AnteriorRespuesta Tengo una respuesta
Search Busqueda sugerida