[Glass] Compacting extent as part of the daily cleanup/backup scripts? Re: Compact a extend0.dbf

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

[Glass] Compacting extent as part of the daily cleanup/backup scripts? Re: Compact a extend0.dbf

Mariano Martinez Peck


On Sat, Jun 7, 2014 at 9:55 AM, Dale Henrichs <[hidden email]> wrote:
Dario, 

The procedure for compacting extent files is:

  1. make a full backup
  2. shut down stone
  3. cp a virgin extent ($GEMSTONE/bin/extent0.seaside.dbf) into your
      data directory
  4. start stone
  5 restore from backup


Hi Dale,

I had a similar scenario today. My extent is about 11GB and 9GB out of them are free. I get that doing   '(SystemRepository freeSpace / 1024 / 1024 ) asFloat  greaseString'.
So...yes, yeah, I would like to compact this extent. 

Now...I have backup and cleanup strings every day which do a MFC and reclaim, make full backup, and remove unnecessary tranlogs according to last backup. Very much as the script you provided me from ss3.  So I was wondering if the compact of the extent could also be part of this scripts.  Would it be worth?  I guess I must measure myself right? I mean, I can compacting it a the beginning of a business day, and see how much free space I have again at night? Then regarding that answer, I can consider whether do this daily, or weekly or ...

Another question is...I guess that when you make the extent bigger there is some cost associated. So...I don't want to be compacting frequently (say every day) if then the app will run slower because it is making bigger the extent all the time. 

Thanks in advance, 


 
Dale


On Sat, Jun 7, 2014 at 2:14 AM, Dario Trussardi <[hidden email]> wrote:
Ciao,

        i have a 3.1.0.4   extend0.dbf   file  with dimensions of 13GB.

        The     SystemRepository freeSpace     report    more of 12 GB .

        Now my questions is :

                i can compact the  extend0.dbf          so as to have a more manageable file.

        If yes the compacting it 's a long time procedures?

        It's a risky procedure ?


        Thank for any help,


                Dario
_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass


_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass




--
Mariano
http://marianopeck.wordpress.com

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass
Reply | Threaded
Open this post in threaded view
|

Re: [Glass] Compacting extent as part of the daily cleanup/backup scripts? Re: Compact a extend0.dbf

GLASS mailing list



On Mon, Aug 18, 2014 at 10:58 AM, Mariano Martinez Peck <[hidden email]> wrote:


On Sat, Jun 7, 2014 at 9:55 AM, Dale Henrichs <[hidden email]> wrote:
Dario, 

The procedure for compacting extent files is:

  1. make a full backup
  2. shut down stone
  3. cp a virgin extent ($GEMSTONE/bin/extent0.seaside.dbf) into your
      data directory
  4. start stone
  5 restore from backup


Hi Dale,

I had a similar scenario today. My extent is about 11GB and 9GB out of them are free. I get that doing   '(SystemRepository freeSpace / 1024 / 1024 ) asFloat  greaseString'.
So...yes, yeah, I would like to compact this extent. 

Now...I have backup and cleanup strings every day which do a MFC and reclaim, make full backup, and remove unnecessary tranlogs according to last backup. Very much as the script you provided me from ss3.  So I was wondering if the compact of the extent could also be part of this scripts.  Would it be worth?  I guess I must measure myself right? I mean, I can compacting it a the beginning of a business day, and see how much free space I have again at night? Then regarding that answer, I can consider whether do this daily, or weekly or ...

Another question is...I guess that when you make the extent bigger there is some cost associated. So...I don't want to be compacting frequently (say every day) if then the app will run slower because it is making bigger the extent all the time. 

I think that the main consideration in extent size is how much disk space you have available...

there really isn't much of a penalty for having free space in your extents.

On the other hand, there is a rall performance penalty for growing your extents ... if you don't have enough free space in an extent the system will have to allocate more disk space for the extent and that can add to disk i/o load on your system while the extent is grown ... 

So at the end of the day, you really only need to shrink your extents when you are in danger of running out of disk space for tranlogs or other files ...

Dale

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass