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?
> 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.
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.
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
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
[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.
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.
> 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.
+1
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?
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
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)
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.
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.