Extent management on replication enabled database

Posted by Tarmo R on 17-Feb-2020 14:26

What is the best practice of managing database extents for a replication enabled database running on 10.2B08?

If i create the extents structure the way I like it and add a variable extent to the end of each area, then how should I go about adding new extents? I understand, that the normal practice of removing the variable extent before adding new properly sized fixed extents is not possible on replication enabled databases without breaking and re-enabling replication from scratch. Should I just accept, that there will be a 64kb extent in between big extents and the next one will again be a properly sized data extent?

This would also be solved by having an ability to define an initial size for a variable extent instead of the maximum, but there seems to be no way for that?

Posted by gus bjorklund on 18-Feb-2020 19:10

> On Feb 17, 2020, at 3:47 PM, Tarmo R wrote:

>

> I was just under the impression, that official recommendation from Progress is still to use pre-allocated extents for best performance

remember the old saying "best is the enemy of good.".

while it is true that preallocating extents can give "best" performance, (as james said) the incremental improvement over variable extents is quite small with modern filesystems. so not worth worrying about except in extremem cases where every possible small advantage is needed.

Posted by James Palmer on 18-Feb-2020 07:25

With well configured direct attached storage, even spinning rust,, the performance gain from fixed extents is not worth the hassle. Even if you're forced to use a SAN you're probably not going to notice the difference.

Posted by James Palmer on 17-Feb-2020 15:49

Initial sizing etc is a feature that's been introduced in version 12. Hint hint! :)

In a sense it doesn't really matter what size the extents are. It's just file sizes. It will make little differences to the day to day operation. Make sure the database has large files enabled and as long as you have disk space you'll not crash. Then just add the extent when it reaches an arbitrary size.

Note: Enabling large files can be done without reseeding Replication, but it has to be enabled on both sides at the same time. knowledgebase.progress.com/.../P126424

All Replies

Posted by James Palmer on 17-Feb-2020 15:49

Initial sizing etc is a feature that's been introduced in version 12. Hint hint! :)

In a sense it doesn't really matter what size the extents are. It's just file sizes. It will make little differences to the day to day operation. Make sure the database has large files enabled and as long as you have disk space you'll not crash. Then just add the extent when it reaches an arbitrary size.

Note: Enabling large files can be done without reseeding Replication, but it has to be enabled on both sides at the same time. knowledgebase.progress.com/.../P126424

Posted by Tarmo R on 17-Feb-2020 20:45

[quote user="James Palmer"]

Initial sizing etc is a feature that's been introduced in version 12. Hint hint! :)[/quote]Well that's off the table for at least another 10 years, I guess. :) We are stuck anyway with the Progress version, that our applicaton vendor supports and we are only just now planning to update application to the current version in two years time and getting Progress 11 with that. It's a healthcare application also - who knows, when they feel confident enough to do a major upgrade to the underlying technology.

[quote]In a sense it doesn't really matter what size the extents are. It's just file sizes. It will make little differences to the day to day operation. Make sure the database has large files enabled and as long as you have disk space you'll not crash. Then just add the extent when it reaches an arbitrary size.

Note: Enabling large files can be done without reseeding Replication, but it has to be enabled on both sides at the same time. knowledgebase.progress.com/.../P126424[/quote]Large files are already enabled, that's not an issue at this time. I was just under the impression, that official recommendation from Progress is still to use pre-allocated extents for best performance, so just letting the variable extent grow until it looks decent and then switching did not seem like a best idea.

Posted by James Palmer on 18-Feb-2020 07:25

With well configured direct attached storage, even spinning rust,, the performance gain from fixed extents is not worth the hassle. Even if you're forced to use a SAN you're probably not going to notice the difference.

Posted by gus bjorklund on 18-Feb-2020 19:10

> On Feb 17, 2020, at 3:47 PM, Tarmo R wrote:

>

> I was just under the impression, that official recommendation from Progress is still to use pre-allocated extents for best performance

remember the old saying "best is the enemy of good.".

while it is true that preallocating extents can give "best" performance, (as james said) the incremental improvement over variable extents is quite small with modern filesystems. so not worth worrying about except in extremem cases where every possible small advantage is needed.

Posted by mfurgal on 18-Feb-2020 19:20

To add my 2-cents.  I agree with Gus and James on the performance impact between fixed and variable extents being negligible, however there is another advantage to fixed extents which is pre-allocating the database growth.  This prevents an unplanned outage due to an out of disk space situation as the database is always growing within its pre-allocated container. 
 
I know of a few customers that like the fact that they can “consume” the space for the database as their system engineers are stingy on disk space allocation and do not like to see 50GB or 100GB of unused space on a filesystem.  Preallocating some of that space makes it in use, which makes the DBA happy and the system engineer happy, or at least fooled.
 
Mike
-- 
Mike Furgal
Director – Database and Pro2 Services
PROGRESS
617-803-2870 
 
 

Posted by gus bjorklund on 18-Feb-2020 19:30

+1

Posted by ChUIMonster on 18-Feb-2020 19:38

I confess to not having had an opportunity to experiment with it but there is a new feature to grow variable extents out to defined sizes.  This should let you avoid the need to delete an unused variable extent before adding a new fixed extent.

I'm not sure when that was released.  12.1 maybe?

Posted by James Palmer on 18-Feb-2020 21:08

I thought it was 12.0, but you could be right. You can certainly specify a size for a variable extent now. See the example here: documentation.progress.com/.../index.html

Posted by Richard Banville on 18-Feb-2020 21:42

Released with OpenEdge Release 12.1

A description was included in the presentation I gave at EMEA PUG 2019 and is in the OpenEdge 12.1 documentation.

You can create new pre-extended variable length extents by specifying the "x" attribute in the .st file and doing a prostrct create or add/addonline operation.

You can pre-extend an existing variable length extent by specifying the "e" attribute in the .st file and doing a prostrct add/addonline operation.

These pre-extented extents act just like regular variable length extents once the pre-extended size is exceeded so no additional management headaches with those ai files, just the best in performance.

Works for all extent types (ai, bi, d)

To Mike's point about not using all the disk space available, you can use pre-extended variable length extents in conjunction with the existing "v" attribute in the .st file to specify maximum growth of the variable length extent (as far as I know, few people have ever used the existing "v" attribute)

Posted by James Palmer on 19-Feb-2020 13:46

Thanks for confirming, Rich. I realised the link I posted above is for 11.7! It's so hard to find anything in the documentation for V12.

Posted by Tarmo R on 21-Feb-2020 09:09

Thank you all for the replies and discussion. I will just add some new fixed extents and not worry too much about some tiny extents in between. I still like to have the extents preallocated.

This thread is closed