Amigos,
Hemos aprendido la importancia de particionar tablas, y también bajo que condiciones es conveniente optar por hacerlo...
.
Hemos dado 5 pasos para la partición de una tabla http://gherrerasqlserver.blogspot.com.ar/2013/05/particionar-tablas-en-5-pasos.html
Pues bien, siguiendo con el mismo ejemplo hemos de entender cómo mantener la partición creada.
Recordemos que en nuestro ejemplo habíamos particionado la tabla llamada "VENTAS".
[dbo].[ventas]([id] [int] NULL,
[fecha] [datetime] NULL, ---> idx_fecha (clustered)
[idproducto] [int] NULL,
[cantidad] [int] NULL)
Esta tabla contenía 20 millones de registros, lo cuales fueron reasignados a 4 data files distintos acorde al siguiente Partition Function:
[PF_Ventas](datetime)
As Range Left For Values
('2011-06-30 23:59:59', '2011-12-31 23:59:59','2012-06-30 23:59:59' )
Y que habíamos mapeado los registros a los filegroups creados acorde al siguiente Partition Scheme:
[PS_Ventas] As Partition [PF_Ventas]
To ([Fg_Ventas_20011A], [Fg_Ventas_20011B] , [Fg_Ventas_20012A], [Fg_Ventas_20012B] )
Pues bien amigos, la pregunta es...
Qué pasa cuando comienzo el primer semestre del año 2013?, Dónde serán sincronizados los registros?
Si no hacemos un trabajo de mantenimiento de la partición, todos los registros del primer semestre del 2013 serán asignados al Filegroup [Fg_Ventas_20012B] , por exceder el último límite de nuestro Partition Function (2012-06-30 23:59:59' ).
Esto es muy malo, pues el datafile contenido en el filegroup [Fg_Ventas_2012B] comenzará a crecer desbalanceando nuestra tabla particionada y, por consiguiente, provocando lentos pero progresivos problemas de performance a medida que vaya creciendo el archivo mencionado.
Vamos entonces a tomar cartas en el asunto. (recomiendo, como siempre, hacer este tipo de trabajos con la Base de Datos en modo "Single User"):
Primer Paso : Agregar Un Nuevo Filegroup Para Contener los Datos el File Con los Datos del Primer Semestre del 2013
Alter Database Prueba
Add FileGroup [Fg_Ventas_20013A]
Segundo Paso : Agregar Files Para los Filegroups Creados
Alter Database Prueba
Add File
(Name = 'ventas_2013A',
Filename = 'H:\Data\ventas2013A.ndf',
Size = 25000MB,
Maxsize = 100000MB)
To Filegroup [Fg_Ventas_20013A]
Tercer Paso : Moficar El Partition Scheme Para Mapear al Mismo el Nuevo FileGroup Creado en el primer paso
Alter Partition Scheme [PS_Ventas]
Next Used [Fg_Ventas_20013A]
Cuarto Paso : Moficar El Partition Function Agregando un Nuevo Limite
Alter Partition Function [PF_Ventas]
Split Range ('2012-12-31 23:59:59')
(**) En este cuarto paso los datos del 2013 son reasignados a la partición nueva. Esto hará crecer nuestro archivo de log y demorará unos minutos (proporcionales a la cantidad de registros del año 2013 que ya hubiese ingresado a nuestra tabla)
LISTO! Nuestra Tabla Particionada ya Está Preparada Para Recibir los Datos del 2013 !!!
Nota: es recomendable que no nos dejemos "llegar el agua al cuello" y , siguiendo con este ejemplo, hagamos este trabajo de mantenimiento de nuestra tabla particionada, antes de la finalización del año 2012.
Esto sería todo amigos... pero... Qué pasa si borramos todos los datos correspondientes al primer semestre del año 2011 (ya que de contaduría nos indican que ya no es necesario tenerlos en línea)?
La respuesta sería..." Mmm pues bien, he borrado los datos, y ahora me sobra una partición (la del primer semestre del 2011)."
Por suerte Microsoft pensó en nosotros y nos dió la oportunidad de hacer algo llamado "Merge" para tal fin, Se implementa el Merge siguiendo estos pasos: (suponiendo que ya hemos borrado de la tabla Ventas todos los registros del primer semestre del 2011)
Primer Paso : Se hace un Merge de la Partición más Vieja con La Partición Inmediatamente Superior (deja de existir la partición 2011A, la cual es absorbida por la 2011B)
Alter Partition Function PF_Ventas()
Merge Range ('2011-06-30 23:59:59')
Segundo Paso : Ya podemos borrar el File y el FileGroup en Desuso...
Alter Database [Prueba] Remove File [Ventas_2011A]
Alter Database [Prueba] Remove FileGroup [Fg_Ventas_20011A]
Y bien amigos, ahora si hemos llegado al fin de este capítulo.
Espero haber sido claro y quedo a vuestra entera disposición.
Un placer tenerlos del otro lado :)
ss Gustavo Herrera.
Otro Artículo Recomendado por el Autor
"Mantenimiento de Estadíasticas Para Una Performance Optima de Nuestra BD"
https://www.blogger.com/blogger.g?blogID=4841087034568585749#editor/target=post;postID=5281491474180357583;onPublishedMenu=allposts;onClosedMenu=allposts;postNum=0;src=postname
Hemos aprendido la importancia de particionar tablas, y también bajo que condiciones es conveniente optar por hacerlo...
.
Hemos dado 5 pasos para la partición de una tabla http://gherrerasqlserver.blogspot.com.ar/2013/05/particionar-tablas-en-5-pasos.html
Pues bien, siguiendo con el mismo ejemplo hemos de entender cómo mantener la partición creada.
Recordemos que en nuestro ejemplo habíamos particionado la tabla llamada "VENTAS".
[dbo].[ventas]([id] [int] NULL,
[fecha] [datetime] NULL, ---> idx_fecha (clustered)
[idproducto] [int] NULL,
[cantidad] [int] NULL)
Esta tabla contenía 20 millones de registros, lo cuales fueron reasignados a 4 data files distintos acorde al siguiente Partition Function:
[PF_Ventas](datetime)
As Range Left For Values
('2011-06-30 23:59:59', '2011-12-31 23:59:59','2012-06-30 23:59:59' )
Y que habíamos mapeado los registros a los filegroups creados acorde al siguiente Partition Scheme:
[PS_Ventas] As Partition [PF_Ventas]
To ([Fg_Ventas_20011A], [Fg_Ventas_20011B] , [Fg_Ventas_20012A], [Fg_Ventas_20012B] )
Pues bien amigos, la pregunta es...
Qué pasa cuando comienzo el primer semestre del año 2013?, Dónde serán sincronizados los registros?
Si no hacemos un trabajo de mantenimiento de la partición, todos los registros del primer semestre del 2013 serán asignados al Filegroup [Fg_Ventas_20012B] , por exceder el último límite de nuestro Partition Function (2012-06-30 23:59:59' ).
Esto es muy malo, pues el datafile contenido en el filegroup [Fg_Ventas_2012B] comenzará a crecer desbalanceando nuestra tabla particionada y, por consiguiente, provocando lentos pero progresivos problemas de performance a medida que vaya creciendo el archivo mencionado.
Vamos entonces a tomar cartas en el asunto. (recomiendo, como siempre, hacer este tipo de trabajos con la Base de Datos en modo "Single User"):
Primer Paso : Agregar Un Nuevo Filegroup Para Contener los Datos el File Con los Datos del Primer Semestre del 2013
Alter Database Prueba
Add FileGroup [Fg_Ventas_20013A]
Segundo Paso : Agregar Files Para los Filegroups Creados
Alter Database Prueba
Add File
(Name = 'ventas_2013A',
Filename = 'H:\Data\ventas2013A.ndf',
Size = 25000MB,
Maxsize = 100000MB)
To Filegroup [Fg_Ventas_20013A]
Tercer Paso : Moficar El Partition Scheme Para Mapear al Mismo el Nuevo FileGroup Creado en el primer paso
Alter Partition Scheme [PS_Ventas]
Next Used [Fg_Ventas_20013A]
Cuarto Paso : Moficar El Partition Function Agregando un Nuevo Limite
Alter Partition Function [PF_Ventas]
Split Range ('2012-12-31 23:59:59')
(**) En este cuarto paso los datos del 2013 son reasignados a la partición nueva. Esto hará crecer nuestro archivo de log y demorará unos minutos (proporcionales a la cantidad de registros del año 2013 que ya hubiese ingresado a nuestra tabla)
LISTO! Nuestra Tabla Particionada ya Está Preparada Para Recibir los Datos del 2013 !!!
Nota: es recomendable que no nos dejemos "llegar el agua al cuello" y , siguiendo con este ejemplo, hagamos este trabajo de mantenimiento de nuestra tabla particionada, antes de la finalización del año 2012.
Esto sería todo amigos... pero... Qué pasa si borramos todos los datos correspondientes al primer semestre del año 2011 (ya que de contaduría nos indican que ya no es necesario tenerlos en línea)?
La respuesta sería..." Mmm pues bien, he borrado los datos, y ahora me sobra una partición (la del primer semestre del 2011)."
Por suerte Microsoft pensó en nosotros y nos dió la oportunidad de hacer algo llamado "Merge" para tal fin, Se implementa el Merge siguiendo estos pasos: (suponiendo que ya hemos borrado de la tabla Ventas todos los registros del primer semestre del 2011)
Primer Paso : Se hace un Merge de la Partición más Vieja con La Partición Inmediatamente Superior (deja de existir la partición 2011A, la cual es absorbida por la 2011B)
Alter Partition Function PF_Ventas()
Merge Range ('2011-06-30 23:59:59')
Segundo Paso : Ya podemos borrar el File y el FileGroup en Desuso...
Alter Database [Prueba] Remove File [Ventas_2011A]
Alter Database [Prueba] Remove FileGroup [Fg_Ventas_20011A]
Y bien amigos, ahora si hemos llegado al fin de este capítulo.
Espero haber sido claro y quedo a vuestra entera disposición.
Un placer tenerlos del otro lado :)
ss Gustavo Herrera.
Otro Artículo Recomendado por el Autor
"Mantenimiento de Estadíasticas Para Una Performance Optima de Nuestra BD"
https://www.blogger.com/blogger.g?blogID=4841087034568585749#editor/target=post;postID=5281491474180357583;onPublishedMenu=allposts;onClosedMenu=allposts;postNum=0;src=postname