protop storage areas

Posted by pwhybrow_2000 on 21-Oct-2019 22:27

At what point do you recommend adding an extent to replace the variable extent?

I have a fixed extent that is full and the variable at 86% of the size of the fixed.  

>  25 Index_Txn3              1000000    856440   1856440   1856316       124    186% 

Plenty of disk space so not worried there.  

Posted by ChUIMonster on 21-Oct-2019 23:54

You have a decision to make.  You are either going to try to stay ahead of things and (try to) add fixed extents before you start writing to the variable extent *or* you might decide that you're not worried about that and you will just let the fixed extents grow.

For many people with small to medium databases the "don't worry about it" option makes a lot of sense.

If you have a larger database then you might want to be more proactive.

Personally I'm not calling anything less than 1TB "large" anymore and it doesn't really bother me to see 64GB extents.  Other people have other opinions.  You do need to be careful about getting carried away -- there is a very hard limit of 1TB for an extent and there is no recovery if you try to exceed it.

In that case the metric that you probably want to pay attention to is %LastX.  That is the percentage full of the last variable extent.  

In your case, since you are already writing to the variable extent, so %LastX should be 100%.  If so then it is too late to be proactive, you have already overflowed, but that's ok, you just end up with a funky sized extent in the middle of all the others.

If you are going to be actively managing things commercial ProTop has an alert that fires when the last fixed extent reaches a threshold (generally 80%).  (Free ProTop does not fire any alerts.)

All Replies

Posted by ChUIMonster on 21-Oct-2019 23:54

You have a decision to make.  You are either going to try to stay ahead of things and (try to) add fixed extents before you start writing to the variable extent *or* you might decide that you're not worried about that and you will just let the fixed extents grow.

For many people with small to medium databases the "don't worry about it" option makes a lot of sense.

If you have a larger database then you might want to be more proactive.

Personally I'm not calling anything less than 1TB "large" anymore and it doesn't really bother me to see 64GB extents.  Other people have other opinions.  You do need to be careful about getting carried away -- there is a very hard limit of 1TB for an extent and there is no recovery if you try to exceed it.

In that case the metric that you probably want to pay attention to is %LastX.  That is the percentage full of the last variable extent.  

In your case, since you are already writing to the variable extent, so %LastX should be 100%.  If so then it is too late to be proactive, you have already overflowed, but that's ok, you just end up with a funky sized extent in the middle of all the others.

If you are going to be actively managing things commercial ProTop has an alert that fires when the last fixed extent reaches a threshold (generally 80%).  (Free ProTop does not fire any alerts.)

Posted by Dapeng Wu on 22-Oct-2019 11:23

Just want to share with you that in OE 12.1, we have added some new features to managing variable length extents. For example, you can use the "e" attribute in the .st file to extend a variable length extent to certain fixed size, then add a new variable extent (which can use the "x" attribute to pre-extend it to certain size).

By doing this, you can avoid the "funky sized extent in the middle of all the others".

Posted by mfurgal on 22-Oct-2019 13:40

Opinions will vary and it may get religious.  I have seen many different type of implementation for storage areas and sizes of extents.  Some made sense to me, others had me shaking my head.  In my opinion, each Storage Area should be made up of us less than 10 extents (files).  If the storage area is less than 10 GB, then 1 or 2 extents are fine.  Large storage areas require larger extents, but there is no need to have 5 extents for a storage area that is less than 1 GB.  Yes, I have seen this many times.
 
I think what happens at times is that someone did something that made sense 10 years ago when the database was 20 GB, and now the database is 200 GB and the storage area design hasn’t been updated, so same sized files are added to storage areas that are growing so now the database is made up of a large number of smaller files.
 
Final word on extent sizes.  If your machine is fast (both CPU and Disk), then you can have large files.  If the machine is slower, then you need smaller files.  If you can do a database repair scan on a 64 GB extent in an hour or so, then 64 GB is a fine size.  But if it takes 5-10 hours, then it is too large.  I say this because all the repair utilities are based on extents.  They can’t start in the middle of an extent, they always start either at the beginning or end of an extent to do it’s scanning.  This will affect any disastrous repair downtime dramatically.  And I know, no one ever thinks they will need to use these repair utilities.  But if that was the case, we would have not built them.
 
Mike
-- 
Mike Furgal
Director – Database and Pro2 Services
PROGRESS
617-803-2870 
 
 

Posted by Dmitri Levin on 12-Dec-2019 21:38

Right. Just because something was making sense 10 years ago does not mean it will make sense now. And what makes sense now will not make in the future, Progress should have the ability to grow an existing extents. It is great that OE 12.1 allows to grow a variable extent to a certain size, but how about fixed extents? It would be nice to grow them too.

10 years ago I set my Oracle DB extents to 5 GB, The database is growing, I changed extents to 10 GB a while back, now I make extents 20 GB each and in 5 years I do not know how much I will make them. Oracle allows me to grow fixed length extents. Nice feature. And having that all the conversation what is the right and what is not right -- does not matter. You make what ever size you want.
BTW in Oracle I can even shrink the fixed extent, provided that it's HWM allows to do that, i.e shrink only Empty blocks. That is probably not that needed, only if accidentally someone makes a too big extent.

This thread is closed