Particionado fisico de tablas SQL 2005

24/01/2008 - 15:30 por msnews.microsoft.com | Informe spam
Hola a todos

hace un tiempo prupuse la siguiente pregunta, tan solo recibi una
contestacion (que acabo de ver en
http://www.microsoft.com/communitie....aspx?...,
aunque normalmente uso el Outlook express, pero este solo me carga los
ultimos 15 dias, y por razones de salud no he asistido el ultimo mes al
trabajo, asi que perdonenm que me repita)

el la unica respuesta se me peguntaba ::
Antes de haber evaluado la particion vieron porque son
lentas las consultas?
hicieron algun profiler? vieron los planes?

y decir, que si, y la mayor parte del problema con la velocidad reside
en :
los acessos a los disco (tenemos indices en las tablas, y las
consultas no son complejas, sumas, avg, min, max, algun left join, poco mas)
y el tamaño de las consultas es considerable (la tabla en cuestion
sufre varios miles de lineas al dia, sobre 250mil lineas mensuales)


asi que paso a mostrar mi pregunta, una vez mas gracias por adelantado

-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-

queria comentaros un caso que tenemos con los tiempos de acceso a una
determinada tabla y creemos que la solucion pasa por el particionado, pero
no estoy seguro como funciona y que rendimiento habria de esperar

segun tengo entendido, y a grandes rasgos, la mejor solucion seria un
particionado fisico de los datos

"bussines case" :: tabla de ventas, donde las escrituras se producen cada
hora y las lecturas continuamente, siendo los periodos mas consultados (en
orden por numero de consultas) ::
- ultima semana cerrada
- ultimo mes cerrado
- ultimas ventas (ultimos 2 o 3 dias)
- otros periodos

actualemtne tenemos una sola tabla, cuyo resultado son tiempos de espera
bastante largos cuando no bloqueos
primeramente pensamos en una particion logica (diferentes tablas) pero
creemos que la particion fisica seria mas eficiente (ademas de evitar tener
que cambiar el flujo de datos)

asi pensamos en dividir la tabla en las siguientes particiones

una, la mas grande y menor usada para todas las ventas anteriores a
principios de año (muy pocas consultas, y ninguna escritura)
cinco particiones mas en las que se escribirian una semana en cada una, asi
ventas__1 :: semana 1, semana 6, semana 11 ...
ventas__2 :: semana 2, semana 7, semana 12 ...
ventas__3 :: semana 3, semana 8, semana 13...
ventas__4 :: semana 4, semana 9 ...
ventas__5 :: semana 5, semana 10 ...

de esta forma raramente se leeria de la misma tabla en la que se esta
escribiendo, y el aceso a los datos (por ejemplo para ultimo mes cerrado) se
podria acelerar enormemente (aceso paralelo a un volumen de datos mucho
menor)

asi mismo pensamos en ampliar el numero de discos del servidor (actualmente
cuenta con dos para datos) incluyendo cinco dedicados para estos menesteres
(serian discos de no mucha capacidad, pero alta velocidad, con lo cual el
precio tampoco seria unn factor importante)

preguntas ::

es este particionamiento posible ??
habria que borrar y recargar los datos o se puede hacer on-live ??
al final de año, podrian los datos moverse de alguna forma de una particion
(dedicada) a la otra (la grande)


agradeceria por supuesto si me indicais alguna direccion donde podriamos
aprender un poco mas

gracias por adelantado

Preguntas similare

Leer las respuestas

#1 Gux (MVP)
24/01/2008 - 20:45 | Informe spam
Mi primera impresión y sin poder analizar en vivo la situación es que
particionar las tablas es un cambio excesivo para la situación. Parece ser
que las lecturas se enlentecen debido a que hay una gran cantidad de
escrituras en los datos (o sea, hay contención o bloqueos).

Mi primera recomendación es:

1. Analicen cómo se hacen las escrituras. Tal vez hay transacciones
demasiado largas que provocan bloqueos.

2. Analicen los indices que tiene la tabla en busca de indices innecesarios.

3. Intenten hacer las consultas con un isolation level más permisivo (ver en
los Books Online: SET ISOLATION LEVEL) o usando hints (buscar en los Books
Online).

Personalmente gastaria un poco de tiempo para analizar esos temas antes de
tomar la decisión de particionar físicamente la tabla.


Gustavo Larriera, Microsoft MVP
https://mvp.support.microsoft.com/profile/gux
Este mensaje se proporciona tal como es, sin garantías de ninguna clase.



"msnews.microsoft.com" wrote:

Hola a todos

hace un tiempo prupuse la siguiente pregunta, tan solo recibi una
contestacion (que acabo de ver en
http://www.microsoft.com/communitie....aspx?...,
aunque normalmente uso el Outlook express, pero este solo me carga los
ultimos 15 dias, y por razones de salud no he asistido el ultimo mes al
trabajo, asi que perdonenm que me repita)

el la unica respuesta se me peguntaba ::
Antes de haber evaluado la particion vieron porque son
lentas las consultas?
hicieron algun profiler? vieron los planes?

y decir, que si, y la mayor parte del problema con la velocidad reside
en :
los acessos a los disco (tenemos indices en las tablas, y las
consultas no son complejas, sumas, avg, min, max, algun left join, poco mas)
y el tamaño de las consultas es considerable (la tabla en cuestion
sufre varios miles de lineas al dia, sobre 250mil lineas mensuales)


asi que paso a mostrar mi pregunta, una vez mas gracias por adelantado

-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-

queria comentaros un caso que tenemos con los tiempos de acceso a una
determinada tabla y creemos que la solucion pasa por el particionado, pero
no estoy seguro como funciona y que rendimiento habria de esperar

segun tengo entendido, y a grandes rasgos, la mejor solucion seria un
particionado fisico de los datos

"bussines case" :: tabla de ventas, donde las escrituras se producen cada
hora y las lecturas continuamente, siendo los periodos mas consultados (en
orden por numero de consultas) ::
- ultima semana cerrada
- ultimo mes cerrado
- ultimas ventas (ultimos 2 o 3 dias)
- otros periodos

actualemtne tenemos una sola tabla, cuyo resultado son tiempos de espera
bastante largos cuando no bloqueos
primeramente pensamos en una particion logica (diferentes tablas) pero
creemos que la particion fisica seria mas eficiente (ademas de evitar tener
que cambiar el flujo de datos)

asi pensamos en dividir la tabla en las siguientes particiones

una, la mas grande y menor usada para todas las ventas anteriores a
principios de año (muy pocas consultas, y ninguna escritura)
cinco particiones mas en las que se escribirian una semana en cada una, asi
ventas__1 :: semana 1, semana 6, semana 11 ...
ventas__2 :: semana 2, semana 7, semana 12 ...
ventas__3 :: semana 3, semana 8, semana 13...
ventas__4 :: semana 4, semana 9 ...
ventas__5 :: semana 5, semana 10 ...

de esta forma raramente se leeria de la misma tabla en la que se esta
escribiendo, y el aceso a los datos (por ejemplo para ultimo mes cerrado) se
podria acelerar enormemente (aceso paralelo a un volumen de datos mucho
menor)

asi mismo pensamos en ampliar el numero de discos del servidor (actualmente
cuenta con dos para datos) incluyendo cinco dedicados para estos menesteres
(serian discos de no mucha capacidad, pero alta velocidad, con lo cual el
precio tampoco seria unn factor importante)

preguntas ::

es este particionamiento posible ??
habria que borrar y recargar los datos o se puede hacer on-live ??
al final de año, podrian los datos moverse de alguna forma de una particion
(dedicada) a la otra (la grande)


agradeceria por supuesto si me indicais alguna direccion donde podriamos
aprender un poco mas

gracias por adelantado





email Siga el debate Respuesta Responder a este mensaje
Ads by Google
Help Hacer una preguntaRespuesta Tengo una respuesta
Search Busqueda sugerida