Table Fragmentation
A user on IDS 11.50.FC5 fragmented a 150M-row history table by month (expression/partitions) so old data could be dropped by detaching a fragment, but each DETACH of a ~30M-row partition took about an hour and held an exclusive lock, instead of the seconds others reported. Suggestions included checking for lock waits, update statistics and extent sizing, plus Art Kagel's point that an index not following the table's fragmentation forces a full index rebuild. That was the cause: four foreign keys had implicit, non-fragmented indexes. Dropping them cut the detach to one second; creating those indexes explicitly (fragmented like the table) before adding the constraints was advised as the fix.
Auto-generated by DrWatson from the posts below — may be imperfect; read the full thread.
Hi! I have an historic table (5 months) with about 30 millions record per month. Our primary problem is that deleting old data takes too long (we have some indexes in that table). So I start making some tests with fragmentation. I fragment my table with a date expression (monthly), using partitions, so here are some question I have about fragmentation. - It takes like 1 hour to detach a 30 million row partition (1 month). Are these normal times? Any idea how can I get better times with that amount of data? Everywhere I read people talk about seconds to detach a partition. - Attaching and Detaching result in an exclusive lock in my table. Is there some way to avoid an exclusive lock? I use IBM Informix Dynamic Server Version 11.50.FC5 Thanks and Regards Emiliano Romero
Assuming you have your table partitioned properly by month per your saying, correct, it should take seconds (or at least in my experience). I think the one hour you encountered was mostly for waiting for an available exclusive lock - which may be hard for an active large table. You may want to try timing again on a real test environment and make sure there is absolutely no access to that table. Kern -- ----- Original Message ---- From: Emiliano Romero <eromero@sitrack.com> To: ids@iiug.org Sent: Wed, March 3, 2010 8:53:52 AM Subject: Table Fragmentation [19170] Hi! I have an historic table (5 months) with about 30 millions record per month. Our primary problem is that deleting old data takes too long (we have some indexes in that table). So I start making some tests with fragmentation. I fragment my table with a date expression (monthly), using partitions, so here are some question I have about fragmentation. - It takes like 1 hour to detach a 30 million row partition (1 month). Are these normal times? Any idea how can I get better times with that amount of data? Everywhere I read people talk about seconds to detach a partition. - Attaching and Detaching result in an exclusive lock in my table. Is there some way to avoid an exclusive lock? I use IBM Informix Dynamic Server Version 11.50.FC5 Thanks and Regards Emiliano Romero ******************************************************************************* Forum Note: Use "Reply" to post a response in the discussion forum.
Kern, thanks for your reply. I'm on a test enviroment, no one is connecting to this server. My fragmention expresion is: fragment by expression partition partpositionold (fechaposicion < datetime(2009-10-01 00:00:00) year to second ) in datadbs, partition partposicion10_09 ((fechaposicion < datetime(2009-11-01 00:00:00) year to second ) AND (fechaposicion >= datetime(2009-10-01 00:00:00) year to second ) ) in datadbs, partition partposicion11_09 ((fechaposicion < datetime(2009-12-01 00:00:00) year to second ) AND (fechaposicion >= datetime(2009-11-01 00:00:00) year to second ) ) in datadbs, partition partposicion12_09 ((fechaposicion < datetime(2010-01-01 00:00:00) year to second ) AND (fechaposicion >= datetime(2009-12-01 00:00:00) year to second ) ) in datadbs, partition partposicion01_10 ((fechaposicion < datetime(2010-02-01 00:00:00) year to second ) AND (fechaposicion >= datetime(2010-01-01 00:00:00) year to second ) ) in datadbs, partition partpositionnew (fechaposicion >= datetime(2010-02-01 00:00:00) year to second ) in datadbs; alter table "informix".posicion modify extent size 2500000 next size 400000; I'm detaching partition partposicion10_09 and it takes 1 hour. I also test using another dbspace but times are the same. As you say that it should take seconds, I'm going to keep playing around with this. Thanks and Regards. [cid:part1.00050002.01080805@sitrack.com] Kern Doe escribió: Assuming you have your table partitioned properly by month per your saying, correct, it should take seconds (or at least in my experience). I think the one hour you encountered was mostly for waiting for an available exclusive lock - which may be hard for an active large table. You may want to try timing again on a real test environment and make sure there is absolutely no access to that table. Kern -- ----- Original Message ---- From: Emiliano Romero [1]<eromero@sitrack.com> To: [2]ids@iiug.org Sent: Wed, March 3, 2010 8:53:52 AM Subject: Table Fragmentation [19170] Hi! I have an historic table (5 months) with about 30 millions record per month. Our primary problem is that deleting old data takes too long (we have some indexes in that table). So I start making some tests with fragmentation. I fragment my table with a date expression (monthly), using partitions, so here are some question I have about fragmentation. - It takes like 1 hour to detach a 30 million row partition (1 month). Are these normal times? Any idea how can I get better times with that amount of data? Everywhere I read people talk about seconds to detach a partition. - Attaching and Detaching result in an exclusive lock in my table. Is there some way to avoid an exclusive lock? I use IBM Informix Dynamic Server Version 11.50.FC5 Thanks and Regards Emiliano Romero ******************************************************************************* Forum Note: Use "Reply" to post a response in the discussion forum. ******************************************************************************* Forum Note: Use "Reply" to post a response in the discussion forum. References 1. mailto:eromero@sitrack.com 2. mailto:ids@iiug.org
Kern, thanks for your reply. I'm on a test enviroment, no one is connecting to this server. My fragmention expresion is: fragment by expression partition partpositionold (fechaposicion < datetime(2009-10-01 00:00:00) year to second ) in datadbs, partition partposicion10_09 ((fechaposicion < datetime(2009-11-01 00:00:00) year to second ) AND (fechaposicion >= datetime(2009-10-01 00:00:00) year to second ) ) in datadbs, partition partposicion11_09 ((fechaposicion < datetime(2009-12-01 00:00:00) year to second ) AND (fechaposicion >= datetime(2009-11-01 00:00:00) year to second ) ) in datadbs, partition partposicion12_09 ((fechaposicion < datetime(2010-01-01 00:00:00) year to second ) AND (fechaposicion >= datetime(2009-12-01 00:00:00) year to second ) ) in datadbs, partition partposicion01_10 ((fechaposicion < datetime(2010-02-01 00:00:00) year to second ) AND (fechaposicion >= datetime(2010-01-01 00:00:00) year to second ) ) in datadbs, partition partpositionnew (fechaposicion >= datetime(2010-02-01 00:00:00) year to second ) in datadbs; alter table "informix".posicion modify extent size 2500000 next size 400000; I'm detaching partition partposicion10_09 and it takes 1 hour. I also test using another dbspace but times are the same. As you say that it should take seconds, I'm going to keep playing around with this. P/S: Sorry about last mail goes in HTML by error. Thanks and Regards. Kern Doe escribió: > Assuming you have your table partitioned properly by month per your saying, > correct, it should take seconds (or at least in my experience). I think the > one hour you encountered was mostly for waiting for an available exclusive > lock - which may be hard for an active large table. > You may want to try timing again on a real test environment and make sure > there is absolutely no access to that table. > Kern -- > > ----- Original Message ---- > From: Emiliano Romero <eromero@sitrack.com> > To: ids@iiug.org > Sent: Wed, March 3, 2010 8:53:52 AM > Subject: Table Fragmentation [19170] > > Hi! I have an historic table (5 months) with about 30 millions record > per month. Our primary problem is that deleting old data takes too long > (we have some indexes in that table). So I start making some tests with > fragmentation. > I fragment my table with a date expression (monthly), using partitions, > so here are some question I have about fragmentation. > > - It takes like 1 hour to detach a 30 million row partition (1 month). > Are these normal times? Any idea how can I get better times with that > amount of data? Everywhere I read people talk about seconds to detach a > partition. > > - Attaching and Detaching result in an exclusive lock in my table. Is > there some way to avoid an exclusive lock? > > I use IBM Informix Dynamic Server Version 11.50.FC5 > > Thanks and Regards > > Emiliano Romero > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. > > >
Just a quick question, Do the indexes on this table follow the tables fragmentation scheme or do they have their own expression? John F. Miller III STSM, Support Architect miller3@us.ibm.com 503-578-5645 IBM Informix Dynamic Server (IDS) ids-bounces@iiug.org wrote on 03/03/2010 07:59:34 AM: > Kern, thanks for your reply. I'm on a test enviroment, no one is > connecting to this server. My fragmention expresion is: > fragment by expression > > partition partpositionold (fechaposicion < datetime(2009-10-01 > > 00:00:00) year to second ) in datadbs, > > partition partposicion10_09 ((fechaposicion < datetime(2009-11-01 > > 00:00:00) year to second ) AND (fechaposicion >=3D > > datetime(2009-10-01 00:00:00) year to second ) > > ) in datadbs, > > partition partposicion11_09 ((fechaposicion < datetime(2009-12-01 > > 00:00:00) year to second ) AND (fechaposicion >=3D > > datetime(2009-11-01 00:00:00) year to second ) > > ) in datadbs, > > partition partposicion12_09 ((fechaposicion < datetime(2010-01-01 > > 00:00:00) year to second ) AND (fechaposicion >=3D > > datetime(2009-12-01 00:00:00) year to second ) > > ) in datadbs, > > partition partposicion01_10 ((fechaposicion < datetime(2010-02-01 > > 00:00:00) year to second ) AND (fechaposicion >=3D > > datetime(2010-01-01 00:00:00) year to second ) > > ) in datadbs, > > partition partpositionnew (fechaposicion >=3D datetime(2010-02-01 > > 00:00:00) year to second ) in datadbs; > alter table "informix".posicion modify > extent size 2500000 next size 400000; > > I'm detaching partition partposicion10_09 and it takes 1 hour. I also= > test using another dbspace but times are the same. > > As you say that it should take seconds, I'm going to keep playing aro= und > with this. > > P/S: Sorry about last mail goes in HTML by error. > > Thanks and Regards. > > Kern Doe escribi=F3: > > Assuming you have your table partitioned properly by month per your= saying, > > correct, it should take seconds (or at least in my experience). I t= hink the > > one hour you encountered was mostly for waiting for an available exclusive > > lock - which may be hard for an active large table. > > You may want to try timing again on a real test environment and mak= e sure > > there is absolutely no access to that table. > > Kern -- > > > > ----- Original Message ---- > > From: Emiliano Romero <eromero@sitrack.com> > > To: ids@iiug.org > > Sent: Wed, March 3, 2010 8:53:52 AM > > Subject: Table Fragmentation [19170] > > > > Hi! I have an historic table (5 months) with about 30 millions reco= rd > > per month. Our primary problem is that deleting old data takes too = long > > (we have some indexes in that table). So I start making some tests = with > > fragmentation. > > I fragment my table with a date expression (monthly), using partiti= ons, > > so here are some question I have about fragmentation. > > > > - It takes like 1 hour to detach a 30 million row partition (1 mont= h). > > Are these normal times? Any idea how can I get better times with th= at > > amount of data? Everywhere I read people talk about seconds to deta= ch a > > partition. > > > > - Attaching and Detaching result in an exclusive lock in my table. = Is > > there some way to avoid an exclusive lock? > > > > I use IBM Informix Dynamic Server Version 11.50.FC5 > > > > Thanks and Regards > > > > Emiliano Romero > > > > > > > ***********************************************************************= ******** > > Forum Note: Use "Reply" to post a response in the discussion forum.= > > > > > > > ***********************************************************************= ******** > > Forum Note: Use "Reply" to post a response in the discussion forum.= > > > > > > > > > ***********************************************************************= ******** > Forum Note: Use "Reply" to post a response in the discussion forum.= >=
John, Indexes follow the table fragmentation. Regards Emiliano Romero John Miller iii escribió: > Just a quick question, Do the indexes on this table > follow the tables fragmentation scheme or do they have their own > expression? > > John F. Miller III > STSM, Support Architect > miller3@us.ibm.com > 503-578-5645 > IBM Informix Dynamic Server (IDS) > > ids-bounces@iiug.org wrote on 03/03/2010 07:59:34 AM: > > >> Kern, thanks for your reply. I'm on a test enviroment, no one is >> connecting to this server. My fragmention expresion is: >> fragment by expression >> >> partition partpositionold (fechaposicion < datetime(2009-10-01 >> >> 00:00:00) year to second ) in datadbs, >> >> partition partposicion10_09 ((fechaposicion < datetime(2009-11-01 >> >> 00:00:00) year to second ) AND (fechaposicion >=3D >> >> datetime(2009-10-01 00:00:00) year to second ) >> >> ) in datadbs, >> >> partition partposicion11_09 ((fechaposicion < datetime(2009-12-01 >> >> 00:00:00) year to second ) AND (fechaposicion >=3D >> >> datetime(2009-11-01 00:00:00) year to second ) >> >> ) in datadbs, >> >> partition partposicion12_09 ((fechaposicion < datetime(2010-01-01 >> >> 00:00:00) year to second ) AND (fechaposicion >=3D >> >> datetime(2009-12-01 00:00:00) year to second ) >> >> ) in datadbs, >> >> partition partposicion01_10 ((fechaposicion < datetime(2010-02-01 >> >> 00:00:00) year to second ) AND (fechaposicion >=3D >> >> datetime(2010-01-01 00:00:00) year to second ) >> >> ) in datadbs, >> >> partition partpositionnew (fechaposicion >=3D datetime(2010-02-01 >> >> 00:00:00) year to second ) in datadbs; >> alter table "informix".posicion modify >> extent size 2500000 next size 400000; >> >> I'm detaching partition partposicion10_09 and it takes 1 hour. I also= >> > > >> test using another dbspace but times are the same. >> >> As you say that it should take seconds, I'm going to keep playing aro= >> > und > >> with this. >> >> P/S: Sorry about last mail goes in HTML by error. >> >> Thanks and Regards. >> >> Kern Doe escribi=F3: >> >>> Assuming you have your table partitioned properly by month per your= >>> > > saying, > >>> correct, it should take seconds (or at least in my experience). I t= >>> > hink > the > >>> one hour you encountered was mostly for waiting for an available >>> > exclusive > >>> lock - which may be hard for an active large table. >>> You may want to try timing again on a real test environment and mak= >>> > e > sure > >>> there is absolutely no access to that table. >>> Kern -- >>> >>> ----- Original Message ---- >>> From: Emiliano Romero <eromero@sitrack.com> >>> To: ids@iiug.org >>> Sent: Wed, March 3, 2010 8:53:52 AM >>> Subject: Table Fragmentation [19170] >>> >>> Hi! I have an historic table (5 months) with about 30 millions reco= >>> > rd > >>> per month. Our primary problem is that deleting old data takes too = >>> > long > > >>> (we have some indexes in that table). So I start making some tests = >>> > with > > >>> fragmentation. >>> I fragment my table with a date expression (monthly), using partiti= >>> > ons, > > >>> so here are some question I have about fragmentation. >>> >>> - It takes like 1 hour to detach a 30 million row partition (1 mont= >>> > h). > >>> Are these normal times? Any idea how can I get better times with th= >>> > at > >>> amount of data? Everywhere I read people talk about seconds to deta= >>> > ch a > > >>> partition. >>> >>> - Attaching and Detaching result in an exclusive lock in my table. = >>> > Is > >>> there some way to avoid an exclusive lock? >>> >>> I use IBM Informix Dynamic Server Version 11.50.FC5 >>> >>> Thanks and Regards >>> >>> Emiliano Romero >>> >>> >>> >>> > ***********************************************************************= > ******** > > >>> Forum Note: Use "Reply" to post a response in the discussion forum.= >>> > > >>> >>> > ***********************************************************************= > ******** > > >>> Forum Note: Use "Reply" to post a response in the discussion forum.= >>> > > >>> >>> >> >> > ***********************************************************************= > ******** > > >> Forum Note: Use "Reply" to post a response in the discussion forum.= >> > > >> = >> > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. > > >
We are experiencing the same behavior on AIX 5300 TL11 using IDS 11.50.FC6. Detaching fragment seems to take a LONG time and chews up an inordinate amount of locks (test system, so we are not waiting on any process or any ad hoc interference). Joe -----Original Message----- From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of Emiliano Romero Sent: Wednesday, March 03, 2010 11:06 AM To: ids@iiug.org Subject: Re: Table Fragmentation [19180] John, Indexes follow the table fragmentation. Regards Emiliano Romero John Miller iii escribió: > Just a quick question, Do the indexes on this table > follow the tables fragmentation scheme or do they have their own > expression? > > John F. Miller III > STSM, Support Architect > miller3@us.ibm.com > 503-578-5645 > IBM Informix Dynamic Server (IDS) > > ids-bounces@iiug.org wrote on 03/03/2010 07:59:34 AM: > > >> Kern, thanks for your reply. I'm on a test enviroment, no one is >> connecting to this server. My fragmention expresion is: >> fragment by expression >> >> partition partpositionold (fechaposicion < datetime(2009-10-01 >> >> 00:00:00) year to second ) in datadbs, >> >> partition partposicion10_09 ((fechaposicion < datetime(2009-11-01 >> >> 00:00:00) year to second ) AND (fechaposicion >=3D >> >> datetime(2009-10-01 00:00:00) year to second ) >> >> ) in datadbs, >> >> partition partposicion11_09 ((fechaposicion < datetime(2009-12-01 >> >> 00:00:00) year to second ) AND (fechaposicion >=3D >> >> datetime(2009-11-01 00:00:00) year to second ) >> >> ) in datadbs, >> >> partition partposicion12_09 ((fechaposicion < datetime(2010-01-01 >> >> 00:00:00) year to second ) AND (fechaposicion >=3D >> >> datetime(2009-12-01 00:00:00) year to second ) >> >> ) in datadbs, >> >> partition partposicion01_10 ((fechaposicion < datetime(2010-02-01 >> >> 00:00:00) year to second ) AND (fechaposicion >=3D >> >> datetime(2010-01-01 00:00:00) year to second ) >> >> ) in datadbs, >> >> partition partpositionnew (fechaposicion >=3D datetime(2010-02-01 >> >> 00:00:00) year to second ) in datadbs; >> alter table "informix".posicion modify >> extent size 2500000 next size 400000; >> >> I'm detaching partition partposicion10_09 and it takes 1 hour. I also= >> > > >> test using another dbspace but times are the same. >> >> As you say that it should take seconds, I'm going to keep playing aro= >> > und > >> with this. >> >> P/S: Sorry about last mail goes in HTML by error. >> >> Thanks and Regards. >> >> Kern Doe escribi=F3: >> >>> Assuming you have your table partitioned properly by month per your= >>> > > saying, > >>> correct, it should take seconds (or at least in my experience). I t= >>> > hink > the > >>> one hour you encountered was mostly for waiting for an available >>> > exclusive > >>> lock - which may be hard for an active large table. >>> You may want to try timing again on a real test environment and mak= >>> > e > sure > >>> there is absolutely no access to that table. >>> Kern -- >>> >>> ----- Original Message ---- >>> From: Emiliano Romero <eromero@sitrack.com> >>> To: ids@iiug.org >>> Sent: Wed, March 3, 2010 8:53:52 AM >>> Subject: Table Fragmentation [19170] >>> >>> Hi! I have an historic table (5 months) with about 30 millions reco= >>> > rd > >>> per month. Our primary problem is that deleting old data takes too = >>> > long > > >>> (we have some indexes in that table). So I start making some tests = >>> > with > > >>> fragmentation. >>> I fragment my table with a date expression (monthly), using partiti= >>> > ons, > > >>> so here are some question I have about fragmentation. >>> >>> - It takes like 1 hour to detach a 30 million row partition (1 mont= >>> > h). > >>> Are these normal times? Any idea how can I get better times with th= >>> > at > >>> amount of data? Everywhere I read people talk about seconds to deta= >>> > ch a > > >>> partition. >>> >>> - Attaching and Detaching result in an exclusive lock in my table. = >>> > Is > >>> there some way to avoid an exclusive lock? >>> >>> I use IBM Informix Dynamic Server Version 11.50.FC5 >>> >>> Thanks and Regards >>> >>> Emiliano Romero >>> >>> >>> >>> > ***********************************************************************= > ******** > > >>> Forum Note: Use "Reply" to post a response in the discussion forum.= >>> > > >>> >>> > ***********************************************************************= > ******** > > >>> Forum Note: Use "Reply" to post a response in the discussion forum.= >>> > > >>> >>> >> >> > ***********************************************************************= > ******** > > >> Forum Note: Use "Reply" to post a response in the discussion forum.= >> > > >> = >> > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. > > > ******************************************************************************* Forum Note: Use "Reply" to post a response in the discussion forum.
Emiliano, Detaching a fragment should generally be very fast, as others have indicated. However, if you have a non-fragmented index or an index that is fragmented on a different strategy, then detaching the fragment will cause the entire index to have to be rebuilt from scratch (which is faster than if the engine just went through and deleted all of the keys you are about to detach). That operation is likely what's slowing you down. Art Art S. Kagel Advanced DataTools (www.advancedatatools.com) IIUG Board of Directors (art@iiug.org) See you at the 2010 IIUG Informix Conference April 25-28, 2010 Overland Park (Kansas City), KS www.iiug.org/conf Disclaimer: Please keep in mind that my own opinions are my own opinions and do not reflect on my employer, Advanced DataTools, the IIUG, nor any other organization with which I am associated either explicitly, implicitly, or by inference. Neither do those opinions reflect those of other individuals affiliated with any entity with which I am affiliated nor those of the entities themselves. On Wed, Mar 3, 2010 at 10:21 AM, Kern Doe <kern_doe@yahoo.com> wrote: > Assuming you have your table partitioned properly by month per your saying, > correct, it should take seconds (or at least in my experience). I think the > one hour you encountered was mostly for waiting for an available exclusive > lock - which may be hard for an active large table. > You may want to try timing again on a real test environment and make sure > there is absolutely no access to that table. > Kern -- > > ----- Original Message ---- > From: Emiliano Romero <eromero@sitrack.com> > To: ids@iiug.org > Sent: Wed, March 3, 2010 8:53:52 AM > Subject: Table Fragmentation [19170] > > Hi! I have an historic table (5 months) with about 30 millions record > per month. Our primary problem is that deleting old data takes too long > (we have some indexes in that table). So I start making some tests with > fragmentation. > I fragment my table with a date expression (monthly), using partitions, > so here are some question I have about fragmentation. > > - It takes like 1 hour to detach a 30 million row partition (1 month). > Are these normal times? Any idea how can I get better times with that > amount of data? Everywhere I read people talk about seconds to detach a > partition. > > - Attaching and Detaching result in an exclusive lock in my table. Is > there some way to avoid an exclusive lock? > > I use IBM Informix Dynamic Server Version 11.50.FC5 > > Thanks and Regards > > Emiliano Romero > > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. > > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. > > --001517447dbadfe0450480ea7247
Your fragmentation scheme looks fine -- and the slowness you have is interesting, I would just try: 1. running update statistics on the table (or/and) 2. review your extent alocation (first/next) in respect to your available space. Please then share your finding. ----- Original Message ---- From: Emiliano Romero <eromero@sitrack.com> To: ids@iiug.org Sent: Wed, March 3, 2010 10:59:34 AM Subject: Re: Table Fragmentation [19175] Kern, thanks for your reply. I'm on a test enviroment, no one is connecting to this server. My fragmention expresion is: fragment by expression partition partpositionold (fechaposicion < datetime(2009-10-01 00:00:00) year to second ) in datadbs, partition partposicion10_09 ((fechaposicion < datetime(2009-11-01 00:00:00) year to second ) AND (fechaposicion >= datetime(2009-10-01 00:00:00) year to second ) ) in datadbs, partition partposicion11_09 ((fechaposicion < datetime(2009-12-01 00:00:00) year to second ) AND (fechaposicion >= datetime(2009-11-01 00:00:00) year to second ) ) in datadbs, partition partposicion12_09 ((fechaposicion < datetime(2010-01-01 00:00:00) year to second ) AND (fechaposicion >= datetime(2009-12-01 00:00:00) year to second ) ) in datadbs, partition partposicion01_10 ((fechaposicion < datetime(2010-02-01 00:00:00) year to second ) AND (fechaposicion >= datetime(2010-01-01 00:00:00) year to second ) ) in datadbs, partition partpositionnew (fechaposicion >= datetime(2010-02-01 00:00:00) year to second ) in datadbs; alter table "informix".posicion modify extent size 2500000 next size 400000; I'm detaching partition partposicion10_09 and it takes 1 hour. I also test using another dbspace but times are the same. As you say that it should take seconds, I'm going to keep playing around with this. P/S: Sorry about last mail goes in HTML by error. Thanks and Regards. Kern Doe escribió: > Assuming you have your table partitioned properly by month per your saying, > correct, it should take seconds (or at least in my experience). I think the > one hour you encountered was mostly for waiting for an available exclusive > lock - which may be hard for an active large table. > You may want to try timing again on a real test environment and make sure > there is absolutely no access to that table. > Kern -- > > ----- Original Message ---- > From: Emiliano Romero <eromero@sitrack.com> > To: ids@iiug.org > Sent: Wed, March 3, 2010 8:53:52 AM > Subject: Table Fragmentation [19170] > > Hi! I have an historic table (5 months) with about 30 millions record > per month. Our primary problem is that deleting old data takes too long > (we have some indexes in that table). So I start making some tests with > fragmentation. > I fragment my table with a date expression (monthly), using partitions, > so here are some question I have about fragmentation. > > - It takes like 1 hour to detach a 30 million row partition (1 month). > Are these normal times? Any idea how can I get better times with that > amount of data? Everywhere I read people talk about seconds to detach a > partition. > > - Attaching and Detaching result in an exclusive lock in my table. Is > there some way to avoid an exclusive lock? > > I use IBM Informix Dynamic Server Version 11.50.FC5 > > Thanks and Regards > > Emiliano Romero > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. > > > ******************************************************************************* Forum Note: Use "Reply" to post a response in the discussion forum.
Ok, first thanks to every one that help me. Uday Kale give's me the solution. The problem was that in my table I have 4 foreign keys, and that implicit indexes are not fragmented with the database fragmentation expresion. I remove that foreign keys and it took 1 second to detach 30 millions rows. Uday told me that explicitly creating those index before constraint creation should fragment index in the same way as table is fragmented. Hope this's the same problem that Joe has. Thanks again and regards Kern Doe escribió: > Your fragmentation scheme looks fine -- and the slowness you have is > interesting, I would just try: > 1. running update statistics on the table (or/and) > 2. review your extent alocation (first/next) in respect to your available > space. > Please then share your finding. > > ----- Original Message ---- > From: Emiliano Romero <eromero@sitrack.com> > To: ids@iiug.org > Sent: Wed, March 3, 2010 10:59:34 AM > Subject: Re: Table Fragmentation [19175] > > Kern, thanks for your reply. I'm on a test enviroment, no one is > connecting to this server. My fragmention expresion is: > fragment by expression > > partition partpositionold (fechaposicion < datetime(2009-10-01 > > 00:00:00) year to second ) in datadbs, > > partition partposicion10_09 ((fechaposicion < datetime(2009-11-01 > > 00:00:00) year to second ) AND (fechaposicion >= > > datetime(2009-10-01 00:00:00) year to second ) > > ) in datadbs, > > partition partposicion11_09 ((fechaposicion < datetime(2009-12-01 > > 00:00:00) year to second ) AND (fechaposicion >= > > datetime(2009-11-01 00:00:00) year to second ) > > ) in datadbs, > > partition partposicion12_09 ((fechaposicion < datetime(2010-01-01 > > 00:00:00) year to second ) AND (fechaposicion >= > > datetime(2009-12-01 00:00:00) year to second ) > > ) in datadbs, > > partition partposicion01_10 ((fechaposicion < datetime(2010-02-01 > > 00:00:00) year to second ) AND (fechaposicion >= > > datetime(2010-01-01 00:00:00) year to second ) > > ) in datadbs, > > partition partpositionnew (fechaposicion >= datetime(2010-02-01 > > 00:00:00) year to second ) in datadbs; > alter table "informix".posicion modify > extent size 2500000 next size 400000; > > I'm detaching partition partposicion10_09 and it takes 1 hour. I also > test using another dbspace but times are the same. > > As you say that it should take seconds, I'm going to keep playing around > with this. > > P/S: Sorry about last mail goes in HTML by error. > > Thanks and Regards. > > Kern Doe escribió: > >> Assuming you have your table partitioned properly by month per your saying, >> correct, it should take seconds (or at least in my experience). I think the >> one hour you encountered was mostly for waiting for an available exclusive >> lock - which may be hard for an active large table. >> You may want to try timing again on a real test environment and make sure >> there is absolutely no access to that table. >> Kern -- >> >> ----- Original Message ---- >> From: Emiliano Romero <eromero@sitrack.com> >> To: ids@iiug.org >> Sent: Wed, March 3, 2010 8:53:52 AM >> Subject: Table Fragmentation [19170] >> >> Hi! I have an historic table (5 months) with about 30 millions record >> per month. Our primary problem is that deleting old data takes too long >> (we have some indexes in that table). So I start making some tests with >> fragmentation. >> I fragment my table with a date expression (monthly), using partitions, >> so here are some question I have about fragmentation. >> >> - It takes like 1 hour to detach a 30 million row partition (1 month). >> Are these normal times? Any idea how can I get better times with that >> amount of data? Everywhere I read people talk about seconds to detach a >> partition. >> >> - Attaching and Detaching result in an exclusive lock in my table. Is >> there some way to avoid an exclusive lock? >> >> I use IBM Informix Dynamic Server Version 11.50.FC5 >> >> Thanks and Regards >> >> Emiliano Romero >> >> >> >> > > ******************************************************************************* > >> Forum Note: Use "Reply" to post a response in the discussion forum. >> >> >> >> > > ******************************************************************************* > >> Forum Note: Use "Reply" to post a response in the discussion forum. >> >> >> >> > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. > > >
As always, this is a very informative explanation I should take notes too. Thanks Art. Emiliano, re-strategize your partition now, think ahead for the last partition scheme "partpositionnew". I assume you will also partition by month same way as the old ones. For any reason where you still want to try timing your detach process with the old partition scheme, try to turn pdq on, it should speed up a little bit. set pdppriority 50; alter fragment ... ----- Original Message ---- From: Art Kagel <art.kagel@gmail.com> To: ids@iiug.org Sent: Wed, March 3, 2010 2:25:50 PM Subject: Re: Table Fragmentation [19189] Emiliano, Detaching a fragment should generally be very fast, as others have indicated. However, if you have a non-fragmented index or an index that is fragmented on a different strategy, then detaching the fragment will cause the entire index to have to be rebuilt from scratch (which is faster than if the engine just went through and deleted all of the keys you are about to detach). That operation is likely what's slowing you down. Art Art S. Kagel Advanced DataTools (www.advancedatatools.com) IIUG Board of Directors (art@iiug.org) See you at the 2010 IIUG Informix Conference April 25-28, 2010 Overland Park (Kansas City), KS www.iiug.org/conf Disclaimer: Please keep in mind that my own opinions are my own opinions and do not reflect on my employer, Advanced DataTools, the IIUG, nor any other organization with which I am associated either explicitly, implicitly, or by inference. Neither do those opinions reflect those of other individuals affiliated with any entity with which I am affiliated nor those of the entities themselves. On Wed, Mar 3, 2010 at 10:21 AM, Kern Doe <kern_doe@yahoo.com> wrote: > Assuming you have your table partitioned properly by month per your saying, > correct, it should take seconds (or at least in my experience). I think the > one hour you encountered was mostly for waiting for an available exclusive > lock - which may be hard for an active large table. > You may want to try timing again on a real test environment and make sure > there is absolutely no access to that table. > Kern -- > > ----- Original Message ---- > From: Emiliano Romero <eromero@sitrack.com> > To: ids@iiug.org > Sent: Wed, March 3, 2010 8:53:52 AM > Subject: Table Fragmentation [19170] > > Hi! I have an historic table (5 months) with about 30 millions record > per month. Our primary problem is that deleting old data takes too long > (we have some indexes in that table). So I start making some tests with > fragmentation. > I fragment my table with a date expression (monthly), using partitions, > so here are some question I have about fragmentation. > > - It takes like 1 hour to detach a 30 million row partition (1 month). > Are these normal times? Any idea how can I get better times with that > amount of data? Everywhere I read people talk about seconds to detach a > partition. > > - Attaching and Detaching result in an exclusive lock in my table. Is > there some way to avoid an exclusive lock? > > I use IBM Informix Dynamic Server Version 11.50.FC5 > > Thanks and Regards > > Emiliano Romero > > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. > > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. > > --001517447dbadfe0450480ea7247 ******************************************************************************* Forum Note: Use "Reply" to post a response in the discussion forum.
We have this table that even when totally empty, it chews through tons of
locks on the detach:
CREATE RAW TABLE monitor_min_sum (
client INTEGER NOT NULL,
program INTEGER NOT NULL,
site VARCHAR(25,0),
phone CHAR(10) NOT NULL,
calldate DATETIME YEAR TO MINUTE NOT NULL,
calls INTEGER NOT NULL
)
FRAGMENT BY EXPRESSION
PARTITION p201003050700 ((calldate >= datetime(2010-03-05 07:00) year to
minute ) AND (calldate <= datetime(2010-03-05 07:59) year to minute ) ) IN
dbs3,
PARTITION p201003050600 ((calldate >= datetime(2010-03-05 06:00) year to
minute ) AND (calldate <= datetime(2010-03-05 06:59) year to minute ) ) IN
dbs3,
PARTITION p201003050500 ((calldate >= datetime(2010-03-05 05:00) year to
minute ) AND (calldate <= datetime(2010-03-05 05:59) year to minute ) ) IN
dbs3,
PARTITION p201003050400 ((calldate >= datetime(2010-03-05 04:00) year to
minute ) AND (calldate <= datetime(2010-03-05 04:59) year to minute ) ) IN
dbs3 .......
.... about 800 PARTITIONS ...
EXTENT SIZE 64 NEXT SIZE 64 LOCK MODE ROW;
CREATE UNIQUE INDEX uix_monitor_min_sum ON monitor_min_sum (
client ASC,
program ASC,
site ASC,
phone ASC,
calldate ASC
) USING btree;
-----Original Message-----
From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of Kern Doe
Sent: Wednesday, March 03, 2010 3:07 PM
To: ids@iiug.org
Subject: Re: Table Fragmentation [19197]
As always, this is a very informative explanation I should take notes too.
Thanks Art.
Emiliano, re-strategize your partition now, think ahead for the last partition
scheme "partpositionnew". I assume you will also partition by month same way
as the old ones.
For any reason where you still want to try timing your detach process with the
old partition scheme, try to turn pdq on, it should speed up a little bit.
set pdppriority 50;
alter fragment ...
----- Original Message ----
From: Art Kagel <art.kagel@gmail.com>
To: ids@iiug.org
Sent: Wed, March 3, 2010 2:25:50 PM
Subject: Re: Table Fragmentation [19189]
Emiliano,
Detaching a fragment should generally be very fast, as others have
indicated. However, if you have a non-fragmented index or an index that is
fragmented on a different strategy, then detaching the fragment will cause
the entire index to have to be rebuilt from scratch (which is faster than if
the engine just went through and deleted all of the keys you are about to
detach). That operation is likely what's slowing you down.
Art
Art S. Kagel
Advanced DataTools (www.advancedatatools.com)
IIUG Board of Directors (art@iiug.org)
See you at the 2010 IIUG Informix Conference
April 25-28, 2010
Overland Park (Kansas City), KS
www.iiug.org/conf
Disclaimer: Please keep in mind that my own opinions are my own opinions and
do not reflect on my employer, Advanced DataTools, the IIUG, nor any other
organization with which I am associated either explicitly, implicitly, or by
inference. Neither do those opinions reflect those of other individuals
affiliated with any entity with which I am affiliated nor those of the
entities themselves.
On Wed, Mar 3, 2010 at 10:21 AM, Kern Doe <kern_doe@yahoo.com> wrote:
> Assuming you have your table partitioned properly by month per your saying,
> correct, it should take seconds (or at least in my experience). I think the
> one hour you encountered was mostly for waiting for an available exclusive
> lock - which may be hard for an active large table.
> You may want to try timing again on a real test environment and make sure
> there is absolutely no access to that table.
> Kern --
>
> ----- Original Message ----
> From: Emiliano Romero <eromero@sitrack.com>
> To: ids@iiug.org
> Sent: Wed, March 3, 2010 8:53:52 AM
> Subject: Table Fragmentation [19170]
>
> Hi! I have an historic table (5 months) with about 30 millions record
> per month. Our primary problem is that deleting old data takes too long
> (we have some indexes in that table). So I start making some tests with
> fragmentation.
> I fragment my table with a date expression (monthly), using partitions,
> so here are some question I have about fragmentation.
>
> - It takes like 1 hour to detach a 30 million row partition (1 month).
> Are these normal times? Any idea how can I get better times with that
> amount of data? Everywhere I read people talk about seconds to detach a
> partition.
>
> - Attaching and Detaching result in an exclusive lock in my table. Is
> there some way to avoid an exclusive lock?
>
> I use IBM Informix Dynamic Server Version 11.50.FC5
>
> Thanks and Regards
>
> Emiliano Romero
>
>
>
>
*******************************************************************************
> Forum Note: Use "Reply" to post a response in the discussion forum.
>
>
>
>
*******************************************************************************
> Forum Note: Use "Reply" to post a response in the discussion forum.
>
>
--001517447dbadfe0450480ea7247
*******************************************************************************
Forum Note: Use "Reply" to post a response in the discussion forum.
*******************************************************************************
Forum Note: Use "Reply" to post a response in the discussion forum.
Plugge, Joe R,
We have a table that has 8 million partitions ( lot more than you have !)
and it has no more than 256 rows in life time. It only takes 3 seconds to
do all types of fragment manipulations.
Do you want to know how we did it?
Franks
On Wed, Mar 3, 2010 at 4:21 PM, Plugge, Joe R. <JRPlugge@west.com> wrote:
> We have this table that even when totally empty, it chews through tons of
> locks on the detach:
>
> CREATE RAW TABLE monitor_min_sum (>
> client INTEGER NOT NULL,
>
> program INTEGER NOT NULL,
>
> site VARCHAR(25,0),
>
> phone CHAR(10) NOT NULL,
>
> calldate DATETIME YEAR TO MINUTE NOT NULL,
>
> calls INTEGER NOT NULL
> )
> FRAGMENT BY EXPRESSION
>
> PARTITION p201003050700 ((calldate >= datetime(2010-03-05 07:00) year to
> minute ) AND (calldate <= datetime(2010-03-05 07:59) year to minute ) ) IN
> dbs3,
>
> PARTITION p201003050600 ((calldate >= datetime(2010-03-05 06:00) year to
> minute ) AND (calldate <= datetime(2010-03-05 06:59) year to minute ) ) IN
> dbs3,
>
> PARTITION p201003050500 ((calldate >= datetime(2010-03-05 05:00) year to
> minute ) AND (calldate <= datetime(2010-03-05 05:59) year to minute ) ) IN
> dbs3,
>
> PARTITION p201003050400 ((calldate >= datetime(2010-03-05 04:00) year to
> minute ) AND (calldate <= datetime(2010-03-05 04:59) year to minute ) ) IN
> dbs3 .......
>
> ..... about 800 PARTITIONS ...
>
> EXTENT SIZE 64 NEXT SIZE 64 LOCK MODE ROW;
>
> CREATE UNIQUE INDEX uix_monitor_min_sum ON monitor_min_sum (>
> client ASC,
>
> program ASC,
>
> site ASC,
>
> phone ASC,
>
> calldate ASC
> ) USING btree;
>
> -----Original Message-----
> From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of Kern
> Doe
> Sent: Wednesday, March 03, 2010 3:07 PM
> To: ids@iiug.org
> Subject: Re: Table Fragmentation [19197]
>
> As always, this is a very informative explanation I should take notes too.
> Thanks Art.
> Emiliano, re-strategize your partition now, think ahead for the last
> partition
> scheme "partpositionnew". I assume you will also partition by month same
> way
> as the old ones.
>
> For any reason where you still want to try timing your detach process with
> the
> old partition scheme, try to turn pdq on, it should speed up a little bit.
>
> set pdppriority 50;
> alter fragment ...
>
> ----- Original Message ----
> From: Art Kagel <art.kagel@gmail.com>
> To: ids@iiug.org
> Sent: Wed, March 3, 2010 2:25:50 PM
> Subject: Re: Table Fragmentation [19189]
>
> Emiliano,
>
> Detaching a fragment should generally be very fast, as others have
> indicated. However, if you have a non-fragmented index or an index that is
> fragmented on a different strategy, then detaching the fragment will cause
> the entire index to have to be rebuilt from scratch (which is faster than
> if
> the engine just went through and deleted all of the keys you are about to
> detach). That operation is likely what's slowing you down.
>
> Art
>
> Art S. Kagel
> Advanced DataTools (www.advancedatatools.com)
> IIUG Board of Directors (art@iiug.org)
>
> See you at the 2010 IIUG Informix Conference
> April 25-28, 2010
> Overland Park (Kansas City), KS
> www.iiug.org/conf
>
> Disclaimer: Please keep in mind that my own opinions are my own opinions
> and
> do not reflect on my employer, Advanced DataTools, the IIUG, nor any other
> organization with which I am associated either explicitly, implicitly, or
> by
> inference. Neither do those opinions reflect those of other individuals
> affiliated with any entity with which I am affiliated nor those of the
> entities themselves.
>
> On Wed, Mar 3, 2010 at 10:21 AM, Kern Doe <kern_doe@yahoo.com> wrote:
>
> > Assuming you have your table partitioned properly by month per your
> saying,
> > correct, it should take seconds (or at least in my experience). I think
> the
> > one hour you encountered was mostly for waiting for an available
> exclusive
> > lock - which may be hard for an active large table.
> > You may want to try timing again on a real test environment and make sure
> > there is absolutely no access to that table.
> > Kern --
> >
> > ----- Original Message ----
> > From: Emiliano Romero <eromero@sitrack.com>
> > To: ids@iiug.org
> > Sent: Wed, March 3, 2010 8:53:52 AM
> > Subject: Table Fragmentation [19170]
> >
> > Hi! I have an historic table (5 months) with about 30 millions record
> > per month. Our primary problem is that deleting old data takes too long
> > (we have some indexes in that table). So I start making some tests with
> > fragmentation.
> > I fragment my table with a date expression (monthly), using partitions,
> > so here are some question I have about fragmentation.
> >
> > - It takes like 1 hour to detach a 30 million row partition (1 month).
> > Are these normal times? Any idea how can I get better times with that
> > amount of data? Everywhere I read people talk about seconds to detach a
> > partition.
> >
> > - Attaching and Detaching result in an exclusive lock in my table. Is
> > there some way to avoid an exclusive lock?
> >
> > I use IBM Informix Dynamic Server Version 11.50.FC5
> >
> > Thanks and Regards
> >
> > Emiliano Romero
> >
> >
> >
> >
>
>
>
>
*******************************************************************************
> > Forum Note: Use "Reply" to post a response in the discussion forum.
> >
> >
> >
> >
>
>
>
>
*******************************************************************************
> > Forum Note: Use "Reply" to post a response in the discussion forum.
> >
> >
>
> --001517447dbadfe0450480ea7247
>
>
>
>
*******************************************************************************
> Forum Note: Use "Reply" to post a response in the discussion forum.
>
>
>
>
*******************************************************************************
> Forum Note: Use "Reply" to post a response in the discussion forum.
>
>
>
>
*******************************************************************************
> Forum Note: Use "Reply" to post a response in the discussion forum.
>
>
--000e0cd5cd6a75a1f20480fd74fd
So, let me understand you here, you have a total of 256 rows, inserted into a
table with 8 million partitions? You sure you don't mean that you have 8
million rows in a table with 256 partitions?
-----Original Message-----
From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of FRANK
Sent: Thursday, March 04, 2010 12:06 PM
To: ids@iiug.org
Subject: Re: Table Fragmentation [19220]
Plugge, Joe R,
We have a table that has 8 million partitions ( lot more than you have !)
and it has no more than 256 rows in life time. It only takes 3 seconds to
do all types of fragment manipulations.
Do you want to know how we did it?
Franks
On Wed, Mar 3, 2010 at 4:21 PM, Plugge, Joe R. <JRPlugge@west.com> wrote:
> We have this table that even when totally empty, it chews through tons of
> locks on the detach:
>
> CREATE RAW TABLE monitor_min_sum (>
> client INTEGER NOT NULL,
>
> program INTEGER NOT NULL,
>
> site VARCHAR(25,0),
>
> phone CHAR(10) NOT NULL,
>
> calldate DATETIME YEAR TO MINUTE NOT NULL,
>
> calls INTEGER NOT NULL
> )
> FRAGMENT BY EXPRESSION
>
> PARTITION p201003050700 ((calldate >= datetime(2010-03-05 07:00) year to
> minute ) AND (calldate <= datetime(2010-03-05 07:59) year to minute ) ) IN
> dbs3,
>
> PARTITION p201003050600 ((calldate >= datetime(2010-03-05 06:00) year to
> minute ) AND (calldate <= datetime(2010-03-05 06:59) year to minute ) ) IN
> dbs3,
>
> PARTITION p201003050500 ((calldate >= datetime(2010-03-05 05:00) year to
> minute ) AND (calldate <= datetime(2010-03-05 05:59) year to minute ) ) IN
> dbs3,
>
> PARTITION p201003050400 ((calldate >= datetime(2010-03-05 04:00) year to
> minute ) AND (calldate <= datetime(2010-03-05 04:59) year to minute ) ) IN
> dbs3 .......
>
> ..... about 800 PARTITIONS ...
>
> EXTENT SIZE 64 NEXT SIZE 64 LOCK MODE ROW;
>
> CREATE UNIQUE INDEX uix_monitor_min_sum ON monitor_min_sum (>
> client ASC,
>
> program ASC,
>
> site ASC,
>
> phone ASC,
>
> calldate ASC
> ) USING btree;
>
> -----Original Message-----
> From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of Kern
> Doe
> Sent: Wednesday, March 03, 2010 3:07 PM
> To: ids@iiug.org
> Subject: Re: Table Fragmentation [19197]
>
> As always, this is a very informative explanation I should take notes too.
> Thanks Art.
> Emiliano, re-strategize your partition now, think ahead for the last
> partition
> scheme "partpositionnew". I assume you will also partition by month same
> way
> as the old ones.
>
> For any reason where you still want to try timing your detach process with
> the
> old partition scheme, try to turn pdq on, it should speed up a little bit.
>
> set pdppriority 50;
> alter fragment ...
>
> ----- Original Message ----
> From: Art Kagel <art.kagel@gmail.com>
> To: ids@iiug.org
> Sent: Wed, March 3, 2010 2:25:50 PM
> Subject: Re: Table Fragmentation [19189]
>
> Emiliano,
>
> Detaching a fragment should generally be very fast, as others have
> indicated. However, if you have a non-fragmented index or an index that is
> fragmented on a different strategy, then detaching the fragment will cause
> the entire index to have to be rebuilt from scratch (which is faster than
> if
> the engine just went through and deleted all of the keys you are about to
> detach). That operation is likely what's slowing you down.
>
> Art
>
> Art S. Kagel
> Advanced DataTools (www.advancedatatools.com)
> IIUG Board of Directors (art@iiug.org)
>
> See you at the 2010 IIUG Informix Conference
> April 25-28, 2010
> Overland Park (Kansas City), KS
> www.iiug.org/conf
>
> Disclaimer: Please keep in mind that my own opinions are my own opinions
> and
> do not reflect on my employer, Advanced DataTools, the IIUG, nor any other
> organization with which I am associated either explicitly, implicitly, or
> by
> inference. Neither do those opinions reflect those of other individuals
> affiliated with any entity with which I am affiliated nor those of the
> entities themselves.
>
> On Wed, Mar 3, 2010 at 10:21 AM, Kern Doe <kern_doe@yahoo.com> wrote:
>
> > Assuming you have your table partitioned properly by month per your
> saying,
> > correct, it should take seconds (or at least in my experience). I think
> the
> > one hour you encountered was mostly for waiting for an available
> exclusive
> > lock - which may be hard for an active large table.
> > You may want to try timing again on a real test environment and make sure
> > there is absolutely no access to that table.
> > Kern --
> >
> > ----- Original Message ----
> > From: Emiliano Romero <eromero@sitrack.com>
> > To: ids@iiug.org
> > Sent: Wed, March 3, 2010 8:53:52 AM
> > Subject: Table Fragmentation [19170]
> >
> > Hi! I have an historic table (5 months) with about 30 millions record
> > per month. Our primary problem is that deleting old data takes too long
> > (we have some indexes in that table). So I start making some tests with
> > fragmentation.
> > I fragment my table with a date expression (monthly), using partitions,
> > so here are some question I have about fragmentation.
> >
> > - It takes like 1 hour to detach a 30 million row partition (1 month).
> > Are these normal times? Any idea how can I get better times with that
> > amount of data? Everywhere I read people talk about seconds to detach a
> > partition.
> >
> > - Attaching and Detaching result in an exclusive lock in my table. Is
> > there some way to avoid an exclusive lock?
> >
> > I use IBM Informix Dynamic Server Version 11.50.FC5
> >
> > Thanks and Regards
> >
> > Emiliano Romero
> >
> >
> >
> >
>
>
>
>
*******************************************************************************
> > Forum Note: Use "Reply" to post a response in the discussion forum.
> >
> >
> >
> >
>
>
>
>
*******************************************************************************
> > Forum Note: Use "Reply" to post a response in the discussion forum.
> >
> >
>
> --001517447dbadfe0450480ea7247
>
>
>
>
*******************************************************************************
> Forum Note: Use "Reply" to post a response in the discussion forum.
>
>
>
>
*******************************************************************************
> Forum Note: Use "Reply" to post a response in the discussion forum.
>
>
>
>
*******************************************************************************
> Forum Note: Use "Reply" to post a response in the discussion forum.
>
>
--000e0cd5cd6a75a1f20480fd74fd
*******************************************************************************
Forum Note: Use "Reply" to post a response in the discussion forum.
Joe,
Very sure!
We have 8 million partitions, NOT 8 million rows. Again 8 million
PARTITIONS!!
We have 256 rows in the table.
Actually, the performance is getting better now....
It only takes less than 2 seconds to do all types of fragmentation
operations... no locks need.
Fast enough?
Frank
On Thu, Mar 4, 2010 at 1:14 PM, Plugge, Joe R. <JRPlugge@west.com> wrote:
> So, let me understand you here, you have a total of 256 rows, inserted into
> a
> table with 8 million partitions? You sure you don't mean that you have 8
> million rows in a table with 256 partitions?
>
> -----Original Message-----
> From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of
> FRANK
> Sent: Thursday, March 04, 2010 12:06 PM
> To: ids@iiug.org
> Subject: Re: Table Fragmentation [19220]
>
> Plugge, Joe R,
>
> We have a table that has 8 million partitions ( lot more than you have !)
> and it has no more than 256 rows in life time. It only takes 3 seconds to
> do all types of fragment manipulations.
>
> Do you want to know how we did it?
>
> Franks
>
> On Wed, Mar 3, 2010 at 4:21 PM, Plugge, Joe R. <JRPlugge@west.com> wrote:
>
> > We have this table that even when totally empty, it chews through tons of
> > locks on the detach:
> >
> > CREATE RAW TABLE monitor_min_sum (> >
> > client INTEGER NOT NULL,
> >
> > program INTEGER NOT NULL,
> >
> > site VARCHAR(25,0),
> >
> > phone CHAR(10) NOT NULL,
> >
> > calldate DATETIME YEAR TO MINUTE NOT NULL,
> >
> > calls INTEGER NOT NULL
> > )
> > FRAGMENT BY EXPRESSION
> >
> > PARTITION p201003050700 ((calldate >= datetime(2010-03-05 07:00) year to
> > minute ) AND (calldate <= datetime(2010-03-05 07:59) year to minute ) )
> IN
> > dbs3,
> >
> > PARTITION p201003050600 ((calldate >= datetime(2010-03-05 06:00) year to
> > minute ) AND (calldate <= datetime(2010-03-05 06:59) year to minute ) )
> IN
> > dbs3,
> >
> > PARTITION p201003050500 ((calldate >= datetime(2010-03-05 05:00) year to
> > minute ) AND (calldate <= datetime(2010-03-05 05:59) year to minute ) )
> IN
> > dbs3,
> >
> > PARTITION p201003050400 ((calldate >= datetime(2010-03-05 04:00) year to
> > minute ) AND (calldate <= datetime(2010-03-05 04:59) year to minute ) )
> IN
> > dbs3 .......
> >
> > ..... about 800 PARTITIONS ...
> >
> > EXTENT SIZE 64 NEXT SIZE 64 LOCK MODE ROW;
> >
> > CREATE UNIQUE INDEX uix_monitor_min_sum ON monitor_min_sum (> >
> > client ASC,
> >
> > program ASC,
> >
> > site ASC,
> >
> > phone ASC,
> >
> > calldate ASC
> > ) USING btree;
> >
> > -----Original Message-----
> > From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of
> Kern
> > Doe
> > Sent: Wednesday, March 03, 2010 3:07 PM
> > To: ids@iiug.org
> > Subject: Re: Table Fragmentation [19197]
> >
> > As always, this is a very informative explanation I should take notes
> too.
> > Thanks Art.
> > Emiliano, re-strategize your partition now, think ahead for the last
> > partition
> > scheme "partpositionnew". I assume you will also partition by month same
> > way
> > as the old ones.
> >
> > For any reason where you still want to try timing your detach process
> with
> > the
> > old partition scheme, try to turn pdq on, it should speed up a little
> bit.
> >
> > set pdppriority 50;
> > alter fragment ...
> >
> > ----- Original Message ----
> > From: Art Kagel <art.kagel@gmail.com>
> > To: ids@iiug.org
> > Sent: Wed, March 3, 2010 2:25:50 PM
> > Subject: Re: Table Fragmentation [19189]
> >
> > Emiliano,
> >
> > Detaching a fragment should generally be very fast, as others have
> > indicated. However, if you have a non-fragmented index or an index that
> is
> > fragmented on a different strategy, then detaching the fragment will
> cause
> > the entire index to have to be rebuilt from scratch (which is faster than
> > if
> > the engine just went through and deleted all of the keys you are about to
> > detach). That operation is likely what's slowing you down.
> >
> > Art
> >
> > Art S. Kagel
> > Advanced DataTools (www.advancedatatools.com)
> > IIUG Board of Directors (art@iiug.org)
> >
> > See you at the 2010 IIUG Informix Conference
> > April 25-28, 2010
> > Overland Park (Kansas City), KS
> > www.iiug.org/conf
> >
> > Disclaimer: Please keep in mind that my own opinions are my own opinions
> > and
> > do not reflect on my employer, Advanced DataTools, the IIUG, nor any
> other
> > organization with which I am associated either explicitly, implicitly, or
> > by
> > inference. Neither do those opinions reflect those of other individuals
> > affiliated with any entity with which I am affiliated nor those of the
> > entities themselves.
> >
> > On Wed, Mar 3, 2010 at 10:21 AM, Kern Doe <kern_doe@yahoo.com> wrote:
> >
> > > Assuming you have your table partitioned properly by month per your
> > saying,
> > > correct, it should take seconds (or at least in my experience). I think
> > the
> > > one hour you encountered was mostly for waiting for an available
> > exclusive
> > > lock - which may be hard for an active large table.
> > > You may want to try timing again on a real test environment and make
> sure
> > > there is absolutely no access to that table.
> > > Kern --
> > >
> > > ----- Original Message ----
> > > From: Emiliano Romero <eromero@sitrack.com>
> > > To: ids@iiug.org
> > > Sent: Wed, March 3, 2010 8:53:52 AM
> > > Subject: Table Fragmentation [19170]
> > >
> > > Hi! I have an historic table (5 months) with about 30 millions record
> > > per month. Our primary problem is that deleting old data takes too long
> > > (we have some indexes in that table). So I start making some tests with
> > > fragmentation.
> > > I fragment my table with a date expression (monthly), using partitions,
> > > so here are some question I have about fragmentation.
> > >
> > > - It takes like 1 hour to detach a 30 million row partition (1 month).
> > > Are these normal times? Any idea how can I get better times with that
> > > amount of data? Everywhere I read people talk about seconds to detach a
> > > partition.
> > >
> > > - Attaching and Detaching result in an exclusive lock in my table. Is
> > > there some way to avoid an exclusive lock?
> > >
> > > I use IBM Informix Dynamic Server Version 11.50.FC5
> > >
> > > Thanks and Regards
> > >
> > > Emiliano Romero
> > >
> > >
> > >
> > >
> >
> >
> >
> >
>
>
>
*******************************************************************************
> > > Forum Note: Use "Reply" to post a response in the discussion forum.
> > >
> > >
> > >
> > >
> >
> >
> >
> >
>
>
>
*******************************************************************************
> > > Forum Note: Use "Reply" to post a response in the discussion forum.
> > >
> > >
> >
> > --001517447dbadfe0450480ea7247
Why?
Art
Art S. Kagel
Advanced DataTools (www.advancedatatools.com)
IIUG Board of Directors (art@iiug.org)
See you at the 2010 IIUG Informix Conference
April 25-28, 2010
Overland Park (Kansas City), KS
www.iiug.org/conf
Disclaimer: Please keep in mind that my own opinions are my own opinions and
do not reflect on my employer, Advanced DataTools, the IIUG, nor any other
organization with which I am associated either explicitly, implicitly, or by
inference. Neither do those opinions reflect those of other individuals
affiliated with any entity with which I am affiliated nor those of the
entities themselves.
On Thu, Mar 4, 2010 at 2:16 PM, FRANK <yunyaoqu@gmail.com> wrote:
> Joe,
>
> Very sure!
>
> We have 8 million partitions, NOT 8 million rows. Again 8 million
> PARTITIONS!!
>
> We have 256 rows in the table.
>
> Actually, the performance is getting better now....
> It only takes less than 2 seconds to do all types of fragmentation
> operations... no locks need.
> Fast enough?
>
> Frank
>
> On Thu, Mar 4, 2010 at 1:14 PM, Plugge, Joe R. <JRPlugge@west.com> wrote:
>
> > So, let me understand you here, you have a total of 256 rows, inserted
> into
> > a
> > table with 8 million partitions? You sure you don't mean that you have 8
> > million rows in a table with 256 partitions?
> >
> > -----Original Message-----
> > From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of
> > FRANK
> > Sent: Thursday, March 04, 2010 12:06 PM
> > To: ids@iiug.org
> > Subject: Re: Table Fragmentation [19220]
> >
> > Plugge, Joe R,
> >
> > We have a table that has 8 million partitions ( lot more than you have !)
> > and it has no more than 256 rows in life time. It only takes 3 seconds to
> > do all types of fragment manipulations.
> >
> > Do you want to know how we did it?
> >
> > Franks
> >
> > On Wed, Mar 3, 2010 at 4:21 PM, Plugge, Joe R. <JRPlugge@west.com>
> wrote:
> >
> > > We have this table that even when totally empty, it chews through tons
> of
> > > locks on the detach:
> > >
> > > CREATE RAW TABLE monitor_min_sum (> > >
> > > client INTEGER NOT NULL,
> > >
> > > program INTEGER NOT NULL,
> > >
> > > site VARCHAR(25,0),
> > >
> > > phone CHAR(10) NOT NULL,
> > >
> > > calldate DATETIME YEAR TO MINUTE NOT NULL,
> > >
> > > calls INTEGER NOT NULL
> > > )
> > > FRAGMENT BY EXPRESSION
> > >
> > > PARTITION p201003050700 ((calldate >= datetime(2010-03-05 07:00) year
> to
> > > minute ) AND (calldate <= datetime(2010-03-05 07:59) year to minute ) )
> > IN
> > > dbs3,
> > >
> > > PARTITION p201003050600 ((calldate >= datetime(2010-03-05 06:00) year
> to
> > > minute ) AND (calldate <= datetime(2010-03-05 06:59) year to minute ) )
> > IN
> > > dbs3,
> > >
> > > PARTITION p201003050500 ((calldate >= datetime(2010-03-05 05:00) year
> to
> > > minute ) AND (calldate <= datetime(2010-03-05 05:59) year to minute ) )
> > IN
> > > dbs3,
> > >
> > > PARTITION p201003050400 ((calldate >= datetime(2010-03-05 04:00) year
> to
> > > minute ) AND (calldate <= datetime(2010-03-05 04:59) year to minute ) )
> > IN
> > > dbs3 .......
> > >
> > > ..... about 800 PARTITIONS ...
> > >
> > > EXTENT SIZE 64 NEXT SIZE 64 LOCK MODE ROW;
> > >
> > > CREATE UNIQUE INDEX uix_monitor_min_sum ON monitor_min_sum (> > >
> > > client ASC,
> > >
> > > program ASC,
> > >
> > > site ASC,
> > >
> > > phone ASC,
> > >
> > > calldate ASC
> > > ) USING btree;
> > >
> > > -----Original Message-----
> > > From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of
> > Kern
> > > Doe
> > > Sent: Wednesday, March 03, 2010 3:07 PM
> > > To: ids@iiug.org
> > > Subject: Re: Table Fragmentation [19197]
> > >
> > > As always, this is a very informative explanation I should take notes
> > too.
> > > Thanks Art.
> > > Emiliano, re-strategize your partition now, think ahead for the last
> > > partition
> > > scheme "partpositionnew". I assume you will also partition by month
> same
> > > way
> > > as the old ones.
> > >
> > > For any reason where you still want to try timing your detach process
> > with
> > > the
> > > old partition scheme, try to turn pdq on, it should speed up a little
> > bit.
> > >
> > > set pdppriority 50;
> > > alter fragment ...
> > >
> > > ----- Original Message ----
> > > From: Art Kagel <art.kagel@gmail.com>
> > > To: ids@iiug.org
> > > Sent: Wed, March 3, 2010 2:25:50 PM
> > > Subject: Re: Table Fragmentation [19189]
> > >
> > > Emiliano,
> > >
> > > Detaching a fragment should generally be very fast, as others have
> > > indicated. However, if you have a non-fragmented index or an index that
> > is
> > > fragmented on a different strategy, then detaching the fragment will
> > cause
> > > the entire index to have to be rebuilt from scratch (which is faster
> than
> > > if
> > > the engine just went through and deleted all of the keys you are about
> to
> > > detach). That operation is likely what's slowing you down.
> > >
> > > Art
> > >
> > > Art S. Kagel
> > > Advanced DataTools (www.advancedatatools.com)
> > > IIUG Board of Directors (art@iiug.org)
> > >
> > > See you at the 2010 IIUG Informix Conference
> > > April 25-28, 2010
> > > Overland Park (Kansas City), KS
> > > www.iiug.org/conf
> > >
> > > Disclaimer: Please keep in mind that my own opinions are my own
> opinions
> > > and
> > > do not reflect on my employer, Advanced DataTools, the IIUG, nor any
> > other
> > > organization with which I am associated either explicitly, implicitly,
> or
> > > by
> > > inference. Neither do those opinions reflect those of other individuals
> > > affiliated with any entity with which I am affiliated nor those of the
> > > entities themselves.
> > >
> > > On Wed, Mar 3, 2010 at 10:21 AM, Kern Doe <kern_doe@yahoo.com> wrote:
> > >
> > > > Assuming you have your table partitioned properly by month per your
> > > saying,
> > > > correct, it should take seconds (or at least in my experience). I
> think
> > > the
> > > > one hour you encountered was mostly for waiting for an available
> > > exclusive
> > > > lock - which may be hard for an active large table.
> > > > You may want to try timing again on a real test environment and make
> > sure
> > > > there is absolutely no access to that table.
> > > > Kern --
> > > >
> > > > ----- Original Message ----
> > > > From: Emiliano Romero <eromero@sitrack.com>
> > > > To: ids@iiug.org
> > > > Sent: Wed, March 3, 2010 8:53:52 AM
> > > > Subject: Table Fragmentation [19170]
> > > >
> > > > Hi! I have an historic table (5 months) with about 30 millions record
> > > > per month. Our primary problem is that deleting old data takes too
> long
> > > > (we have some indexes in that table). So I start making some tests
> with
> > > > fragmentation.
> > > > I fragment my table with a date expression (monthly), using
> parti
Joe,
8 million rows is not a big deal. No challenge at all.
I think People prefer new challenges, that may be the reason why the table
with 8 million partitions got born.
Luckily, we can handle it well!
Frank
On Thu, Mar 4, 2010 at 2:16 PM, FRANK <yunyaoqu@gmail.com> wrote:
> Joe,
>
> Very sure!
>
> We have 8 million partitions, NOT 8 million rows. Again 8 million
> PARTITIONS!!
>
> We have 256 rows in the table.
>
> Actually, the performance is getting better now....
> It only takes less than 2 seconds to do all types of fragmentation
> operations... no locks need.
> Fast enough?
>
> Frank
>
> On Thu, Mar 4, 2010 at 1:14 PM, Plugge, Joe R. <JRPlugge@west.com> wrote:
>
> > So, let me understand you here, you have a total of 256 rows, inserted
> into
> > a
> > table with 8 million partitions? You sure you don't mean that you have 8
> > million rows in a table with 256 partitions?
> >
> > -----Original Message-----
> > From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of
> > FRANK
> > Sent: Thursday, March 04, 2010 12:06 PM
> > To: ids@iiug.org
> > Subject: Re: Table Fragmentation [19220]
> >
> > Plugge, Joe R,
> >
> > We have a table that has 8 million partitions ( lot more than you have !)
> > and it has no more than 256 rows in life time. It only takes 3 seconds to
> > do all types of fragment manipulations.
> >
> > Do you want to know how we did it?
> >
> > Franks
> >
> > On Wed, Mar 3, 2010 at 4:21 PM, Plugge, Joe R. <JRPlugge@west.com>
> wrote:
> >
> > > We have this table that even when totally empty, it chews through tons
> of
> > > locks on the detach:
> > >
> > > CREATE RAW TABLE monitor_min_sum (> > >
> > > client INTEGER NOT NULL,
> > >
> > > program INTEGER NOT NULL,
> > >
> > > site VARCHAR(25,0),
> > >
> > > phone CHAR(10) NOT NULL,
> > >
> > > calldate DATETIME YEAR TO MINUTE NOT NULL,
> > >
> > > calls INTEGER NOT NULL
> > > )
> > > FRAGMENT BY EXPRESSION
> > >
> > > PARTITION p201003050700 ((calldate >= datetime(2010-03-05 07:00) year
> to
> > > minute ) AND (calldate <= datetime(2010-03-05 07:59) year to minute ) )
> > IN
> > > dbs3,
> > >
> > > PARTITION p201003050600 ((calldate >= datetime(2010-03-05 06:00) year
> to
> > > minute ) AND (calldate <= datetime(2010-03-05 06:59) year to minute ) )
> > IN
> > > dbs3,
> > >
> > > PARTITION p201003050500 ((calldate >= datetime(2010-03-05 05:00) year
> to
> > > minute ) AND (calldate <= datetime(2010-03-05 05:59) year to minute ) )
> > IN
> > > dbs3,
> > >
> > > PARTITION p201003050400 ((calldate >= datetime(2010-03-05 04:00) year
> to
> > > minute ) AND (calldate <= datetime(2010-03-05 04:59) year to minute ) )
> > IN
> > > dbs3 .......
> > >
> > > ..... about 800 PARTITIONS ...
> > >
> > > EXTENT SIZE 64 NEXT SIZE 64 LOCK MODE ROW;
> > >
> > > CREATE UNIQUE INDEX uix_monitor_min_sum ON monitor_min_sum (> > >
> > > client ASC,
> > >
> > > program ASC,
> > >
> > > site ASC,
> > >
> > > phone ASC,
> > >
> > > calldate ASC
> > > ) USING btree;
> > >
> > > -----Original Message-----
> > > From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of
> > Kern
> > > Doe
> > > Sent: Wednesday, March 03, 2010 3:07 PM
> > > To: ids@iiug.org
> > > Subject: Re: Table Fragmentation [19197]
> > >
> > > As always, this is a very informative explanation I should take notes
> > too.
> > > Thanks Art.
> > > Emiliano, re-strategize your partition now, think ahead for the last
> > > partition
> > > scheme "partpositionnew". I assume you will also partition by month
> same
> > > way
> > > as the old ones.
> > >
> > > For any reason where you still want to try timing your detach process
> > with
> > > the
> > > old partition scheme, try to turn pdq on, it should speed up a little
> > bit.
> > >
> > > set pdppriority 50;
> > > alter fragment ...
> > >
> > > ----- Original Message ----
> > > From: Art Kagel <art.kagel@gmail.com>
> > > To: ids@iiug.org
> > > Sent: Wed, March 3, 2010 2:25:50 PM
> > > Subject: Re: Table Fragmentation [19189]
> > >
> > > Emiliano,
> > >
> > > Detaching a fragment should generally be very fast, as others have
> > > indicated. However, if you have a non-fragmented index or an index that
> > is
> > > fragmented on a different strategy, then detaching the fragment will
> > cause
> > > the entire index to have to be rebuilt from scratch (which is faster
> than
> > > if
> > > the engine just went through and deleted all of the keys you are about
> to
> > > detach). That operation is likely what's slowing you down.
> > >
> > > Art
> > >
> > > Art S. Kagel
> > > Advanced DataTools (www.advancedatatools.com)
> > > IIUG Board of Directors (art@iiug.org)
> > >
> > > See you at the 2010 IIUG Informix Conference
> > > April 25-28, 2010
> > > Overland Park (Kansas City), KS
> > > www.iiug.org/conf
> > >
> > > Disclaimer: Please keep in mind that my own opinions are my own
> opinions
> > > and
> > > do not reflect on my employer, Advanced DataTools, the IIUG, nor any
> > other
> > > organization with which I am associated either explicitly, implicitly,
> or
> > > by
> > > inference. Neither do those opinions reflect those of other individuals
> > > affiliated with any entity with which I am affiliated nor those of the
> > > entities themselves.
> > >
> > > On Wed, Mar 3, 2010 at 10:21 AM, Kern Doe <kern_doe@yahoo.com> wrote:
> > >
> > > > Assuming you have your table partitioned properly by month per your
> > > saying,
> > > > correct, it should take seconds (or at least in my experience). I
> think
> > > the
> > > > one hour you encountered was mostly for waiting for an available
> > > exclusive
> > > > lock - which may be hard for an active large table.
> > > > You may want to try timing again on a real test environment and make
> > sure
> > > > there is absolutely no access to that table.
> > > > Kern --
> > > >
> > > > ----- Original Message ----
> > > > From: Emiliano Romero <eromero@sitrack.com>
> > > > To: ids@iiug.org
> > > > Sent: Wed, March 3, 2010 8:53:52 AM
> > > > Subject: Table Fragmentation [19170]
> > > >
> > > > Hi! I have an historic table (5 months) with about 30 millions record
> > > > per month. Our primary problem is that deleting old data takes too
> long
> > > > (we have some indexes in that table). So I start making some tests
> with
> > > > fragmentation.
> > > > I fragment my table with a date expression (monthly), using
> partitions,
> > > > so here are some question I have about fragmentation.
> > > >
> > > > - It takes like 1 hour to detach a 30 million row partition (1
> month).
> > > > Are these normal times? Any idea how can I get better times with that
> > > > amount of data? Everywhere I read people talk about seconds to detach
> a
> > > > partition.
> > > >
> > > > - Attaching and Detaching result in an exclusive loc
Time to perform most fragmentation operations depends more on then number of
rows and the fragmentation of indexes than on the number of partitions.
Art
Art S. Kagel
Advanced DataTools (www.advancedatatools.com)
IIUG Board of Directors (art@iiug.org)
See you at the 2010 IIUG Informix Conference
April 25-28, 2010
Overland Park (Kansas City), KS
www.iiug.org/conf
Disclaimer: Please keep in mind that my own opinions are my own opinions and
do not reflect on my employer, Advanced DataTools, the IIUG, nor any other
organization with which I am associated either explicitly, implicitly, or by
inference. Neither do those opinions reflect those of other individuals
affiliated with any entity with which I am affiliated nor those of the
entities themselves.
On Thu, Mar 4, 2010 at 2:16 PM, FRANK <yunyaoqu@gmail.com> wrote:
> Joe,
>
> Very sure!
>
> We have 8 million partitions, NOT 8 million rows. Again 8 million
> PARTITIONS!!
>
> We have 256 rows in the table.
>
> Actually, the performance is getting better now....
> It only takes less than 2 seconds to do all types of fragmentation
> operations... no locks need.
> Fast enough?
>
> Frank
>
> On Thu, Mar 4, 2010 at 1:14 PM, Plugge, Joe R. <JRPlugge@west.com> wrote:
>
> > So, let me understand you here, you have a total of 256 rows, inserted
> into
> > a
> > table with 8 million partitions? You sure you don't mean that you have 8
> > million rows in a table with 256 partitions?
> >
> > -----Original Message-----
> > From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of
> > FRANK
> > Sent: Thursday, March 04, 2010 12:06 PM
> > To: ids@iiug.org
> > Subject: Re: Table Fragmentation [19220]
> >
> > Plugge, Joe R,
> >
> > We have a table that has 8 million partitions ( lot more than you have !)
> > and it has no more than 256 rows in life time. It only takes 3 seconds to
> > do all types of fragment manipulations.
> >
> > Do you want to know how we did it?
> >
> > Franks
> >
> > On Wed, Mar 3, 2010 at 4:21 PM, Plugge, Joe R. <JRPlugge@west.com>
> wrote:
> >
> > > We have this table that even when totally empty, it chews through tons
> of
> > > locks on the detach:
> > >
> > > CREATE RAW TABLE monitor_min_sum (> > >
> > > client INTEGER NOT NULL,
> > >
> > > program INTEGER NOT NULL,
> > >
> > > site VARCHAR(25,0),
> > >
> > > phone CHAR(10) NOT NULL,
> > >
> > > calldate DATETIME YEAR TO MINUTE NOT NULL,
> > >
> > > calls INTEGER NOT NULL
> > > )
> > > FRAGMENT BY EXPRESSION
> > >
> > > PARTITION p201003050700 ((calldate >= datetime(2010-03-05 07:00) year
> to
> > > minute ) AND (calldate <= datetime(2010-03-05 07:59) year to minute ) )
> > IN
> > > dbs3,
> > >
> > > PARTITION p201003050600 ((calldate >= datetime(2010-03-05 06:00) year
> to
> > > minute ) AND (calldate <= datetime(2010-03-05 06:59) year to minute ) )
> > IN
> > > dbs3,
> > >
> > > PARTITION p201003050500 ((calldate >= datetime(2010-03-05 05:00) year
> to
> > > minute ) AND (calldate <= datetime(2010-03-05 05:59) year to minute ) )
> > IN
> > > dbs3,
> > >
> > > PARTITION p201003050400 ((calldate >= datetime(2010-03-05 04:00) year
> to
> > > minute ) AND (calldate <= datetime(2010-03-05 04:59) year to minute ) )
> > IN
> > > dbs3 .......
> > >
> > > ..... about 800 PARTITIONS ...
> > >
> > > EXTENT SIZE 64 NEXT SIZE 64 LOCK MODE ROW;
> > >
> > > CREATE UNIQUE INDEX uix_monitor_min_sum ON monitor_min_sum (> > >
> > > client ASC,
> > >
> > > program ASC,
> > >
> > > site ASC,
> > >
> > > phone ASC,
> > >
> > > calldate ASC
> > > ) USING btree;
> > >
> > > -----Original Message-----
> > > From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of
> > Kern
> > > Doe
> > > Sent: Wednesday, March 03, 2010 3:07 PM
> > > To: ids@iiug.org
> > > Subject: Re: Table Fragmentation [19197]
> > >
> > > As always, this is a very informative explanation I should take notes
> > too.
> > > Thanks Art.
> > > Emiliano, re-strategize your partition now, think ahead for the last
> > > partition
> > > scheme "partpositionnew". I assume you will also partition by month
> same
> > > way
> > > as the old ones.
> > >
> > > For any reason where you still want to try timing your detach process
> > with
> > > the
> > > old partition scheme, try to turn pdq on, it should speed up a little
> > bit.
> > >
> > > set pdppriority 50;
> > > alter fragment ...
> > >
> > > ----- Original Message ----
> > > From: Art Kagel <art.kagel@gmail.com>
> > > To: ids@iiug.org
> > > Sent: Wed, March 3, 2010 2:25:50 PM
> > > Subject: Re: Table Fragmentation [19189]
> > >
> > > Emiliano,
> > >
> > > Detaching a fragment should generally be very fast, as others have
> > > indicated. However, if you have a non-fragmented index or an index that
> > is
> > > fragmented on a different strategy, then detaching the fragment will
> > cause
> > > the entire index to have to be rebuilt from scratch (which is faster
> than
> > > if
> > > the engine just went through and deleted all of the keys you are about
> to
> > > detach). That operation is likely what's slowing you down.
> > >
> > > Art
> > >
> > > Art S. Kagel
> > > Advanced DataTools (www.advancedatatools.com)
> > > IIUG Board of Directors (art@iiug.org)
> > >
> > > See you at the 2010 IIUG Informix Conference
> > > April 25-28, 2010
> > > Overland Park (Kansas City), KS
> > > www.iiug.org/conf
> > >
> > > Disclaimer: Please keep in mind that my own opinions are my own
> opinions
> > > and
> > > do not reflect on my employer, Advanced DataTools, the IIUG, nor any
> > other
> > > organization with which I am associated either explicitly, implicitly,
> or
> > > by
> > > inference. Neither do those opinions reflect those of other individuals
> > > affiliated with any entity with which I am affiliated nor those of the
> > > entities themselves.
> > >
> > > On Wed, Mar 3, 2010 at 10:21 AM, Kern Doe <kern_doe@yahoo.com> wrote:
> > >
> > > > Assuming you have your table partitioned properly by month per your
> > > saying,
> > > > correct, it should take seconds (or at least in my experience). I
> think
> > > the
> > > > one hour you encountered was mostly for waiting for an available
> > > exclusive
> > > > lock - which may be hard for an active large table.
> > > > You may want to try timing again on a real test environment and make
> > sure
> > > > there is absolutely no access to that table.
> > > > Kern --
> > > >
> > > > ----- Original Message ----
> > > > From: Emiliano Romero <eromero@sitrack.com>
> > > > To: ids@iiug.org
> > > > Sent: Wed, March 3, 2010 8:53:52 AM
> > > > Subject: Table Fragmentation [19170]
> > > >
> > > > Hi! I have an historic table (5 months) with about 30 millions record
> > > > per month. Our primary problem is that deleting old data takes too
> long
> > > > (we have some indexes in that table). So I
Send me your schema , I need a good laugher .... :-)
-----Original Message-----
From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of FRANK
Sent: Thursday, March 04, 2010 1:31 PM
To: ids@iiug.org
Subject: Re: Table Fragmentation [19224]
Joe,
8 million rows is not a big deal. No challenge at all.
I think People prefer new challenges, that may be the reason why the table
with 8 million partitions got born.
Luckily, we can handle it well!
Frank
On Thu, Mar 4, 2010 at 2:16 PM, FRANK <yunyaoqu@gmail.com> wrote:
> Joe,
>
> Very sure!
>
> We have 8 million partitions, NOT 8 million rows. Again 8 million
> PARTITIONS!!
>
> We have 256 rows in the table.
>
> Actually, the performance is getting better now....
> It only takes less than 2 seconds to do all types of fragmentation
> operations... no locks need.
> Fast enough?
>
> Frank
>
> On Thu, Mar 4, 2010 at 1:14 PM, Plugge, Joe R. <JRPlugge@west.com> wrote:
>
> > So, let me understand you here, you have a total of 256 rows, inserted
> into
> > a
> > table with 8 million partitions? You sure you don't mean that you have 8
> > million rows in a table with 256 partitions?
> >
> > -----Original Message-----
> > From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of
> > FRANK
> > Sent: Thursday, March 04, 2010 12:06 PM
> > To: ids@iiug.org
> > Subject: Re: Table Fragmentation [19220]
> >
> > Plugge, Joe R,
> >
> > We have a table that has 8 million partitions ( lot more than you have !)
> > and it has no more than 256 rows in life time. It only takes 3 seconds to
> > do all types of fragment manipulations.
> >
> > Do you want to know how we did it?
> >
> > Franks
> >
> > On Wed, Mar 3, 2010 at 4:21 PM, Plugge, Joe R. <JRPlugge@west.com>
> wrote:
> >
> > > We have this table that even when totally empty, it chews through tons
> of
> > > locks on the detach:
> > >
> > > CREATE RAW TABLE monitor_min_sum (> > >
> > > client INTEGER NOT NULL,
> > >
> > > program INTEGER NOT NULL,
> > >
> > > site VARCHAR(25,0),
> > >
> > > phone CHAR(10) NOT NULL,
> > >
> > > calldate DATETIME YEAR TO MINUTE NOT NULL,
> > >
> > > calls INTEGER NOT NULL
> > > )
> > > FRAGMENT BY EXPRESSION
> > >
> > > PARTITION p201003050700 ((calldate >= datetime(2010-03-05 07:00) year
> to
> > > minute ) AND (calldate <= datetime(2010-03-05 07:59) year to minute ) )
> > IN
> > > dbs3,
> > >
> > > PARTITION p201003050600 ((calldate >= datetime(2010-03-05 06:00) year
> to
> > > minute ) AND (calldate <= datetime(2010-03-05 06:59) year to minute ) )
> > IN
> > > dbs3,
> > >
> > > PARTITION p201003050500 ((calldate >= datetime(2010-03-05 05:00) year
> to
> > > minute ) AND (calldate <= datetime(2010-03-05 05:59) year to minute ) )
> > IN
> > > dbs3,
> > >
> > > PARTITION p201003050400 ((calldate >= datetime(2010-03-05 04:00) year
> to
> > > minute ) AND (calldate <= datetime(2010-03-05 04:59) year to minute ) )
> > IN
> > > dbs3 .......
> > >
> > > ..... about 800 PARTITIONS ...
> > >
> > > EXTENT SIZE 64 NEXT SIZE 64 LOCK MODE ROW;
> > >
> > > CREATE UNIQUE INDEX uix_monitor_min_sum ON monitor_min_sum (> > >
> > > client ASC,
> > >
> > > program ASC,
> > >
> > > site ASC,
> > >
> > > phone ASC,
> > >
> > > calldate ASC
> > > ) USING btree;
> > >
> > > -----Original Message-----
> > > From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of
> > Kern
> > > Doe
> > > Sent: Wednesday, March 03, 2010 3:07 PM
> > > To: ids@iiug.org
> > > Subject: Re: Table Fragmentation [19197]
> > >
> > > As always, this is a very informative explanation I should take notes
> > too.
> > > Thanks Art.
> > > Emiliano, re-strategize your partition now, think ahead for the last
> > > partition
> > > scheme "partpositionnew". I assume you will also partition by month
> same
> > > way
> > > as the old ones.
> > >
> > > For any reason where you still want to try timing your detach process
> > with
> > > the
> > > old partition scheme, try to turn pdq on, it should speed up a little
> > bit.
> > >
> > > set pdppriority 50;
> > > alter fragment ...
> > >
> > > ----- Original Message ----
> > > From: Art Kagel <art.kagel@gmail.com>
> > > To: ids@iiug.org
> > > Sent: Wed, March 3, 2010 2:25:50 PM
> > > Subject: Re: Table Fragmentation [19189]
> > >
> > > Emiliano,
> > >
> > > Detaching a fragment should generally be very fast, as others have
> > > indicated. However, if you have a non-fragmented index or an index that
> > is
> > > fragmented on a different strategy, then detaching the fragment will
> > cause
> > > the entire index to have to be rebuilt from scratch (which is faster
> than
> > > if
> > > the engine just went through and deleted all of the keys you are about
> to
> > > detach). That operation is likely what's slowing you down.
> > >
> > > Art
> > >
> > > Art S. Kagel
> > > Advanced DataTools (www.advancedatatools.com)
> > > IIUG Board of Directors (art@iiug.org)
> > >
> > > See you at the 2010 IIUG Informix Conference
> > > April 25-28, 2010
> > > Overland Park (Kansas City), KS
> > > www.iiug.org/conf
> > >
> > > Disclaimer: Please keep in mind that my own opinions are my own
> opinions
> > > and
> > > do not reflect on my employer, Advanced DataTools, the IIUG, nor any
> > other
> > > organization with which I am associated either explicitly, implicitly,
> or
> > > by
> > > inference. Neither do those opinions reflect those of other individuals
> > > affiliated with any entity with which I am affiliated nor those of the
> > > entities themselves.
> > >
> > > On Wed, Mar 3, 2010 at 10:21 AM, Kern Doe <kern_doe@yahoo.com> wrote:
> > >
> > > > Assuming you have your table partitioned properly by month per your
> > > saying,
> > > > correct, it should take seconds (or at least in my experience). I
> think
> > > the
> > > > one hour you encountered was mostly for waiting for an available
> > > exclusive
> > > > lock - which may be hard for an active large table.
> > > > You may want to try timing again on a real test environment and make
> > sure
> > > > there is absolutely no access to that table.
> > > > Kern --
> > > >
> > > > ----- Original Message ----
> > > > From: Emiliano Romero <eromero@sitrack.com>
> > > > To: ids@iiug.org
> > > > Sent: Wed, March 3, 2010 8:53:52 AM
> > > > Subject: Table Fragmentation [19170]
> > > >
> > > > Hi! I have an historic table (5 months) with about 30 millions record
> > > > per month. Our primary problem is that deleting old data takes too
> long
> > > > (we have some indexes in that table). So I start making some tests
> with
> > > > fragmentation.
> > > > I fragment my table with a date expression (monthly), using
> partitions,
> > > > so here are some question I have about fragmentation.
> > > >
> > > > - It takes like 1 hour to detach a 30 million row partition
Joe,
What is your FTP address? We need upload ( FTP push) to your designated
host.
By the way, we only charge $5.16 per byte today.....
Frank
On Thu, Mar 4, 2010 at 2:44 PM, Plugge, Joe R. <JRPlugge@west.com> wrote:
> Send me your schema , I need a good laugher .... :-)
>
> -----Original Message-----
> From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of
> FRANK
> Sent: Thursday, March 04, 2010 1:31 PM
> To: ids@iiug.org
> Subject: Re: Table Fragmentation [19224]
>
> Joe,
>
> 8 million rows is not a big deal. No challenge at all.
>
> I think People prefer new challenges, that may be the reason why the table
> with 8 million partitions got born.
> Luckily, we can handle it well!
>
> Frank
>
> On Thu, Mar 4, 2010 at 2:16 PM, FRANK <yunyaoqu@gmail.com> wrote:
>
> > Joe,
> >
> > Very sure!
> >
> > We have 8 million partitions, NOT 8 million rows. Again 8 million
> > PARTITIONS!!
> >
> > We have 256 rows in the table.
> >
> > Actually, the performance is getting better now....
> > It only takes less than 2 seconds to do all types of fragmentation
> > operations... no locks need.
> > Fast enough?
> >
> > Frank
> >
> > On Thu, Mar 4, 2010 at 1:14 PM, Plugge, Joe R. <JRPlugge@west.com>
> wrote:
> >
> > > So, let me understand you here, you have a total of 256 rows, inserted
> > into
> > > a
> > > table with 8 million partitions? You sure you don't mean that you have
> 8
> > > million rows in a table with 256 partitions?
> > >
> > > -----Original Message-----
> > > From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of
> > > FRANK
> > > Sent: Thursday, March 04, 2010 12:06 PM
> > > To: ids@iiug.org
> > > Subject: Re: Table Fragmentation [19220]
> > >
> > > Plugge, Joe R,
> > >
> > > We have a table that has 8 million partitions ( lot more than you have
> !)
> > > and it has no more than 256 rows in life time. It only takes 3 seconds
> to
> > > do all types of fragment manipulations.
> > >
> > > Do you want to know how we did it?
> > >
> > > Franks
> > >
> > > On Wed, Mar 3, 2010 at 4:21 PM, Plugge, Joe R. <JRPlugge@west.com>
> > wrote:
> > >
> > > > We have this table that even when totally empty, it chews through
> tons
> > of
> > > > locks on the detach:
> > > >
> > > > CREATE RAW TABLE monitor_min_sum (> > > >
> > > > client INTEGER NOT NULL,
> > > >
> > > > program INTEGER NOT NULL,
> > > >
> > > > site VARCHAR(25,0),
> > > >
> > > > phone CHAR(10) NOT NULL,
> > > >
> > > > calldate DATETIME YEAR TO MINUTE NOT NULL,
> > > >
> > > > calls INTEGER NOT NULL
> > > > )
> > > > FRAGMENT BY EXPRESSION
> > > >
> > > > PARTITION p201003050700 ((calldate >= datetime(2010-03-05 07:00) year
> > to
> > > > minute ) AND (calldate <= datetime(2010-03-05 07:59) year to minute )
> )
> > > IN
> > > > dbs3,
> > > >
> > > > PARTITION p201003050600 ((calldate >= datetime(2010-03-05 06:00) year
> > to
> > > > minute ) AND (calldate <= datetime(2010-03-05 06:59) year to minute )
> )
> > > IN
> > > > dbs3,
> > > >
> > > > PARTITION p201003050500 ((calldate >= datetime(2010-03-05 05:00) year
> > to
> > > > minute ) AND (calldate <= datetime(2010-03-05 05:59) year to minute )
> )
> > > IN
> > > > dbs3,
> > > >
> > > > PARTITION p201003050400 ((calldate >= datetime(2010-03-05 04:00) year
> > to
> > > > minute ) AND (calldate <= datetime(2010-03-05 04:59) year to minute )
> )
> > > IN
> > > > dbs3 .......
> > > >
> > > > ..... about 800 PARTITIONS ...
> > > >
> > > > EXTENT SIZE 64 NEXT SIZE 64 LOCK MODE ROW;
> > > >
> > > > CREATE UNIQUE INDEX uix_monitor_min_sum ON monitor_min_sum (> > > >
> > > > client ASC,
> > > >
> > > > program ASC,
> > > >
> > > > site ASC,
> > > >
> > > > phone ASC,
> > > >
> > > > calldate ASC
> > > > ) USING btree;
> > > >
> > > > -----Original Message-----
> > > > From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf
> Of
> > > Kern
> > > > Doe
> > > > Sent: Wednesday, March 03, 2010 3:07 PM
> > > > To: ids@iiug.org
> > > > Subject: Re: Table Fragmentation [19197]
> > > >
> > > > As always, this is a very informative explanation I should take notes
> > > too.
> > > > Thanks Art.
> > > > Emiliano, re-strategize your partition now, think ahead for the last
> > > > partition
> > > > scheme "partpositionnew". I assume you will also partition by month
> > same
> > > > way
> > > > as the old ones.
> > > >
> > > > For any reason where you still want to try timing your detach process
> > > with
> > > > the
> > > > old partition scheme, try to turn pdq on, it should speed up a little
> > > bit.
> > > >
> > > > set pdppriority 50;
> > > > alter fragment ...
> > > >
> > > > ----- Original Message ----
> > > > From: Art Kagel <art.kagel@gmail.com>
> > > > To: ids@iiug.org
> > > > Sent: Wed, March 3, 2010 2:25:50 PM
> > > > Subject: Re: Table Fragmentation [19189]
> > > >
> > > > Emiliano,
> > > >
> > > > Detaching a fragment should generally be very fast, as others have
> > > > indicated. However, if you have a non-fragmented index or an index
> that
> > > is
> > > > fragmented on a different strategy, then detaching the fragment will
> > > cause
> > > > the entire index to have to be rebuilt from scratch (which is faster
> > than
> > > > if
> > > > the engine just went through and deleted all of the keys you are
> about
> > to
> > > > detach). That operation is likely what's slowing you down.
> > > >
> > > > Art
> > > >
> > > > Art S. Kagel
> > > > Advanced DataTools (www.advancedatatools.com)
> > > > IIUG Board of Directors (art@iiug.org)
> > > >
> > > > See you at the 2010 IIUG Informix Conference
> > > > April 25-28, 2010
> > > > Overland Park (Kansas City), KS
> > > > www.iiug.org/conf
> > > >
> > > > Disclaimer: Please keep in mind that my own opinions are my own
> > opinions
> > > > and
> > > > do not reflect on my employer, Advanced DataTools, the IIUG, nor any
> > > other
> > > > organization with which I am associated either explicitly,
> implicitly,
> > or
> > > > by
> > > > inference. Neither do those opinions reflect those of other
> individuals
> > > > affiliated with any entity with which I am affiliated nor those of
> the
> > > > entities themselves.
> > > >
> > > > On Wed, Mar 3, 2010 at 10:21 AM, Kern Doe <kern_doe@yahoo.com>
> wrote:
> > > >
> > > > > Assuming you have your table partitioned properly by month per your
> > > > saying,
> > > > > correct, it should take seconds (or at least in my experience). I
> > think
> > > > the
> > > > > one hour you encountered was mostly for waiting for an available
> > > > exclusive
> > > > > lock - which may be hard for an active large table.
> > > > > You may want to try timing again on a real test environment and
> make
> > > sure
> > > > > there is absolutely no access to that table.@@NL
That is what I thought .... the schema for your table is larger than the data
that it holds LOL :-)
-----Original Message-----
From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of FRANK
Sent: Thursday, March 04, 2010 1:58 PM
To: ids@iiug.org
Subject: Re: Table Fragmentation [19227]
Joe,
What is your FTP address? We need upload ( FTP push) to your designated
host.
By the way, we only charge $5.16 per byte today.....
Frank
On Thu, Mar 4, 2010 at 2:44 PM, Plugge, Joe R. <JRPlugge@west.com> wrote:
> Send me your schema , I need a good laugher .... :-)
>
> -----Original Message-----
> From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of
> FRANK
> Sent: Thursday, March 04, 2010 1:31 PM
> To: ids@iiug.org
> Subject: Re: Table Fragmentation [19224]
>
> Joe,
>
> 8 million rows is not a big deal. No challenge at all.
>
> I think People prefer new challenges, that may be the reason why the table
> with 8 million partitions got born.
> Luckily, we can handle it well!
>
> Frank
>
> On Thu, Mar 4, 2010 at 2:16 PM, FRANK <yunyaoqu@gmail.com> wrote:
>
> > Joe,
> >
> > Very sure!
> >
> > We have 8 million partitions, NOT 8 million rows. Again 8 million
> > PARTITIONS!!
> >
> > We have 256 rows in the table.
> >
> > Actually, the performance is getting better now....
> > It only takes less than 2 seconds to do all types of fragmentation
> > operations... no locks need.
> > Fast enough?
> >
> > Frank
> >
> > On Thu, Mar 4, 2010 at 1:14 PM, Plugge, Joe R. <JRPlugge@west.com>
> wrote:
> >
> > > So, let me understand you here, you have a total of 256 rows, inserted
> > into
> > > a
> > > table with 8 million partitions? You sure you don't mean that you have
> 8
> > > million rows in a table with 256 partitions?
> > >
> > > -----Original Message-----
> > > From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of
> > > FRANK
> > > Sent: Thursday, March 04, 2010 12:06 PM
> > > To: ids@iiug.org
> > > Subject: Re: Table Fragmentation [19220]
> > >
> > > Plugge, Joe R,
> > >
> > > We have a table that has 8 million partitions ( lot more than you have
> !)
> > > and it has no more than 256 rows in life time. It only takes 3 seconds
> to
> > > do all types of fragment manipulations.
> > >
> > > Do you want to know how we did it?
> > >
> > > Franks
> > >
> > > On Wed, Mar 3, 2010 at 4:21 PM, Plugge, Joe R. <JRPlugge@west.com>
> > wrote:
> > >
> > > > We have this table that even when totally empty, it chews through
> tons
> > of
> > > > locks on the detach:
> > > >
> > > > CREATE RAW TABLE monitor_min_sum (> > > >
> > > > client INTEGER NOT NULL,
> > > >
> > > > program INTEGER NOT NULL,
> > > >
> > > > site VARCHAR(25,0),
> > > >
> > > > phone CHAR(10) NOT NULL,
> > > >
> > > > calldate DATETIME YEAR TO MINUTE NOT NULL,
> > > >
> > > > calls INTEGER NOT NULL
> > > > )
> > > > FRAGMENT BY EXPRESSION
> > > >
> > > > PARTITION p201003050700 ((calldate >= datetime(2010-03-05 07:00) year
> > to
> > > > minute ) AND (calldate <= datetime(2010-03-05 07:59) year to minute )
> )
> > > IN
> > > > dbs3,
> > > >
> > > > PARTITION p201003050600 ((calldate >= datetime(2010-03-05 06:00) year
> > to
> > > > minute ) AND (calldate <= datetime(2010-03-05 06:59) year to minute )
> )
> > > IN
> > > > dbs3,
> > > >
> > > > PARTITION p201003050500 ((calldate >= datetime(2010-03-05 05:00) year
> > to
> > > > minute ) AND (calldate <= datetime(2010-03-05 05:59) year to minute )
> )
> > > IN
> > > > dbs3,
> > > >
> > > > PARTITION p201003050400 ((calldate >= datetime(2010-03-05 04:00) year
> > to
> > > > minute ) AND (calldate <= datetime(2010-03-05 04:59) year to minute )
> )
> > > IN
> > > > dbs3 .......
> > > >
> > > > ..... about 800 PARTITIONS ...
> > > >
> > > > EXTENT SIZE 64 NEXT SIZE 64 LOCK MODE ROW;
> > > >
> > > > CREATE UNIQUE INDEX uix_monitor_min_sum ON monitor_min_sum (> > > >
> > > > client ASC,
> > > >
> > > > program ASC,
> > > >
> > > > site ASC,
> > > >
> > > > phone ASC,
> > > >
> > > > calldate ASC
> > > > ) USING btree;
> > > >
> > > > -----Original Message-----
> > > > From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf
> Of
> > > Kern
> > > > Doe
> > > > Sent: Wednesday, March 03, 2010 3:07 PM
> > > > To: ids@iiug.org
> > > > Subject: Re: Table Fragmentation [19197]
> > > >
> > > > As always, this is a very informative explanation I should take notes
> > > too.
> > > > Thanks Art.
> > > > Emiliano, re-strategize your partition now, think ahead for the last
> > > > partition
> > > > scheme "partpositionnew". I assume you will also partition by month
> > same
> > > > way
> > > > as the old ones.
> > > >
> > > > For any reason where you still want to try timing your detach process
> > > with
> > > > the
> > > > old partition scheme, try to turn pdq on, it should speed up a little
> > > bit.
> > > >
> > > > set pdppriority 50;
> > > > alter fragment ...
> > > >
> > > > ----- Original Message ----
> > > > From: Art Kagel <art.kagel@gmail.com>
> > > > To: ids@iiug.org
> > > > Sent: Wed, March 3, 2010 2:25:50 PM
> > > > Subject: Re: Table Fragmentation [19189]
> > > >
> > > > Emiliano,
> > > >
> > > > Detaching a fragment should generally be very fast, as others have
> > > > indicated. However, if you have a non-fragmented index or an index
> that
> > > is
> > > > fragmented on a different strategy, then detaching the fragment will
> > > cause
> > > > the entire index to have to be rebuilt from scratch (which is faster
> > than
> > > > if
> > > > the engine just went through and deleted all of the keys you are
> about
> > to
> > > > detach). That operation is likely what's slowing you down.
> > > >
> > > > Art
> > > >
> > > > Art S. Kagel
> > > > Advanced DataTools (www.advancedatatools.com)
> > > > IIUG Board of Directors (art@iiug.org)
> > > >
> > > > See you at the 2010 IIUG Informix Conference
> > > > April 25-28, 2010
> > > > Overland Park (Kansas City), KS
> > > > www.iiug.org/conf
> > > >
> > > > Disclaimer: Please keep in mind that my own opinions are my own
> > opinions
> > > > and
> > > > do not reflect on my employer, Advanced DataTools, the IIUG, nor any
> > > other
> > > > organization with which I am associated either explicitly,
> implicitly,
> > or
> > > > by
> > > > inference. Neither do those opinions reflect those of other
> individuals
> > > > affiliated with any entity with which I am affiliated nor those of
> the
> > > > entities themselves.
> > > >
> > > > On Wed, Mar 3, 2010 at 10:21 AM, Kern Doe <kern_doe@yahoo.com>
> wrote:
> > > >
> > > > > Assuming you have your table partitioned properly by month per your
> > > > saying,
> > > > > correct, it should take seconds (or at least in my experience). I
> > think
> > >
That's right Joe, FRANKSTER is still generating the schema for you which is
"not a big deal" "no challenge at all"...
----- Original Message ----
From: "Plugge, Joe R." <JRPlugge@west.com>
To: ids@iiug.org
Sent: Thu, March 4, 2010 2:44:59 PM
Subject: RE: Table Fragmentation [19226]
Send me your schema , I need a good laugher .... :-)
-----Original Message-----
From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of FRANK
Sent: Thursday, March 04, 2010 1:31 PM
To: ids@iiug.org
Subject: Re: Table Fragmentation [19224]
Joe,
8 million rows is not a big deal. No challenge at all.
I think People prefer new challenges, that may be the reason why the table
with 8 million partitions got born.
Luckily, we can handle it well!
Frank
On Thu, Mar 4, 2010 at 2:16 PM, FRANK <yunyaoqu@gmail.com> wrote:
> Joe,
>
> Very sure!
>
> We have 8 million partitions, NOT 8 million rows. Again 8 million
> PARTITIONS!!
>
> We have 256 rows in the table.
>
> Actually, the performance is getting better now....
> It only takes less than 2 seconds to do all types of fragmentation
> operations... no locks need.
> Fast enough?
>
> Frank
>
> On Thu, Mar 4, 2010 at 1:14 PM, Plugge, Joe R. <JRPlugge@west.com> wrote:
>
> > So, let me understand you here, you have a total of 256 rows, inserted
> into
> > a
> > table with 8 million partitions? You sure you don't mean that you have 8
> > million rows in a table with 256 partitions?
> >
> > -----Original Message-----
> > From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of
> > FRANK
> > Sent: Thursday, March 04, 2010 12:06 PM
> > To: ids@iiug.org
> > Subject: Re: Table Fragmentation [19220]
> >
> > Plugge, Joe R,
> >
> > We have a table that has 8 million partitions ( lot more than you have !)
> > and it has no more than 256 rows in life time. It only takes 3 seconds to
> > do all types of fragment manipulations.
> >
> > Do you want to know how we did it?
> >
> > Franks
> >
> > On Wed, Mar 3, 2010 at 4:21 PM, Plugge, Joe R. <JRPlugge@west.com>
> wrote:
> >
> > > We have this table that even when totally empty, it chews through tons
> of
> > > locks on the detach:
> > >
> > > CREATE RAW TABLE monitor_min_sum (> > >
> > > client INTEGER NOT NULL,
> > >
> > > program INTEGER NOT NULL,
> > >
> > > site VARCHAR(25,0),
> > >
> > > phone CHAR(10) NOT NULL,
> > >
> > > calldate DATETIME YEAR TO MINUTE NOT NULL,
> > >
> > > calls INTEGER NOT NULL
> > > )
> > > FRAGMENT BY EXPRESSION
> > >
> > > PARTITION p201003050700 ((calldate >= datetime(2010-03-05 07:00) year
> to
> > > minute ) AND (calldate <= datetime(2010-03-05 07:59) year to minute ) )
> > IN
> > > dbs3,
> > >
> > > PARTITION p201003050600 ((calldate >= datetime(2010-03-05 06:00) year
> to
> > > minute ) AND (calldate <= datetime(2010-03-05 06:59) year to minute ) )
> > IN
> > > dbs3,
> > >
> > > PARTITION p201003050500 ((calldate >= datetime(2010-03-05 05:00) year
> to
> > > minute ) AND (calldate <= datetime(2010-03-05 05:59) year to minute ) )
> > IN
> > > dbs3,
> > >
> > > PARTITION p201003050400 ((calldate >= datetime(2010-03-05 04:00) year
> to
> > > minute ) AND (calldate <= datetime(2010-03-05 04:59) year to minute ) )
> > IN
> > > dbs3 .......
> > >
> > > ..... about 800 PARTITIONS ...
> > >
> > > EXTENT SIZE 64 NEXT SIZE 64 LOCK MODE ROW;
> > >
> > > CREATE UNIQUE INDEX uix_monitor_min_sum ON monitor_min_sum (> > >
> > > client ASC,
> > >
> > > program ASC,
> > >
> > > site ASC,
> > >
> > > phone ASC,
> > >
> > > calldate ASC
> > > ) USING btree;
> > >
> > > -----Original Message-----
> > > From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of
> > Kern
> > > Doe
> > > Sent: Wednesday, March 03, 2010 3:07 PM
> > > To: ids@iiug.org
> > > Subject: Re: Table Fragmentation [19197]
> > >
> > > As always, this is a very informative explanation I should take notes
> > too.
> > > Thanks Art.
> > > Emiliano, re-strategize your partition now, think ahead for the last
> > > partition
> > > scheme "partpositionnew". I assume you will also partition by month
> same
> > > way
> > > as the old ones.
> > >
> > > For any reason where you still want to try timing your detach process
> > with
> > > the
> > > old partition scheme, try to turn pdq on, it should speed up a little
> > bit.
> > >
> > > set pdppriority 50;
> > > alter fragment ...
> > >
> > > ----- Original Message ----
> > > From: Art Kagel <art.kagel@gmail.com>
> > > To: ids@iiug.org
> > > Sent: Wed, March 3, 2010 2:25:50 PM
> > > Subject: Re: Table Fragmentation [19189]
> > >
> > > Emiliano,
> > >
> > > Detaching a fragment should generally be very fast, as others have
> > > indicated. However, if you have a non-fragmented index or an index that
> > is
> > > fragmented on a different strategy, then detaching the fragment will
> > cause
> > > the entire index to have to be rebuilt from scratch (which is faster
> than
> > > if
> > > the engine just went through and deleted all of the keys you are about
> to
> > > detach). That operation is likely what's slowing you down.
> > >
> > > Art
> > >
> > > Art S. Kagel
> > > Advanced DataTools (www.advancedatatools.com)
> > > IIUG Board of Directors (art@iiug.org)
> > >
> > > See you at the 2010 IIUG Informix Conference
> > > April 25-28, 2010
> > > Overland Park (Kansas City), KS
> > > www.iiug.org/conf
> > >
> > > Disclaimer: Please keep in mind that my own opinions are my own
> opinions
> > > and
> > > do not reflect on my employer, Advanced DataTools, the IIUG, nor any
> > other
> > > organization with which I am associated either explicitly, implicitly,
> or
> > > by
> > > inference. Neither do those opinions reflect those of other individuals
> > > affiliated with any entity with which I am affiliated nor those of the
> > > entities themselves.
> > >
> > > On Wed, Mar 3, 2010 at 10:21 AM, Kern Doe <kern_doe@yahoo.com> wrote:
> > >
> > > > Assuming you have your table partitioned properly by month per your
> > > saying,
> > > > correct, it should take seconds (or at least in my experience). I
> think
> > > the
> > > > one hour you encountered was mostly for waiting for an available
> > > exclusive
> > > > lock - which may be hard for an active large table.
> > > > You may want to try timing again on a real test environment and make
> > sure
> > > > there is absolutely no access to that table.
> > > > Kern --
> > > >
> > > > ----- Original Message ----
> > > > From: Emiliano Romero <eromero@sitrack.com>
> > > > To: ids@iiug.org
> > > > Sent: Wed, March 3, 2010 8:53:52 AM
> > > > Subject: Table Fragmentation [19170]
> > > >
> > > > Hi! I have an historic table (5 months) with about 30 millions record
> > > > per month. Our primary problem is that deleting old data takes too
> long
Pienso que seria mas rapido: 1. UNLOAD TO "preservar.unl" SELECT * FROM tabla
WHERE fecha BETWEEN ? AND ?; 2. DROP TABLE tabla; 3. CREATE TABLE tabla; 4.
LOAD FROM "preservar.unl" INSERT INTO tabla; 5. Crear los indices, fragmentos,etc; 6. UPDATE STATISTICS tabla;... Recuerda que cuando se usa "DELETE FROM
tabla WHERE fecha BETWEEN ? and ?" los indices se tienen que actualizar, lo
que consume mucho tiempo + los rows no son fisicamente removidos del .dat y
.idx Yo uso el metodo descrito arriba cuando no hay usuarios activos y siempre
me mantiene mis tablas, indices y el query optimizer optimizado para el mejor
rendimiento!