Change AI Extent Sizes

RaphaelFrei

New Member
Hello,

I'm currently checking some databases structures on my company - Since we're starting to implement Replication and some structures are really old (Including some using Area Type I on Progress 12.8).

My question is regarding the database AI file:

Currently we're using After Image with a fixed size of 1GB and Archive Interval of 960 (16 minutes).
Usually, AI's get changed by time rather than reaching the 1GB. But we had in issue last week where replication was locking some AI and got stuck into a single extent without being possible to change. So we're thinking to use all extents with no-fixed-size, because when a locked extent occurs, we can have more work-time without needing to disable replication on a rush.

Is it a good idea? Our database was about 40GB on the biggest site, with more than 300GB available on the AI File Disk (Another disk drive - Different from the database disk).

I made a new structure file, removing the 'f 1024000' from the AI.

To apply these changes on a production database, is it possible to do online?

Or I'll have to take down the database, remove all extents and them applying the new structure? I looked into this guide from Progress.

Thanks for the help!
(And sorry about too many questions - Started working on DBA really recently)
 
with more than 300GB available on the AI File Disk
I hope your database does not have 300 AI extents of 1 GB size .
So we're thinking to use all extents with no-fixed-size
It's a good idea.
To apply these changes on a production database, is it possible to do online?
You can add the AI extents online. V12.8 prostrct removeonline can remove online only data extents:
Unrecognized extent type sports.a3 for prostrct removeonline utility
 
Thanks George!

We'll be working, initially, with 10 AI extents - We don't generate that many data for more extents.
 
What would experts say about the optimal number of variable-length AI extents? 3 is the minimum. What is the best practice?
We don't generate that many data for more extents.
About (or less than) 1 MB/sec (less than 1 GB per 16 min) -> 300 GB of disc space will give you 3.5 days to fix an issue. Great!
 
So we're thinking to use all extents with no-fixed-size
It's a good idea.
Agreed. In the past, some have argued in favour of using fixed-length extents to avoid paying the (theoretical) computational cost of extending the files. OpenEdge now provides the ability to pre-extend variable-length extents, so that should prevent having to pay that cost, and thus this justification for using fixed-length extents, which are a pain to manage.

What would experts say about the optimal number of variable-length AI extents? 3 is the minimum. What is the best practice?

About (or less than) 1 MB/sec (less than 1 GB per 16 min) -> 300 GB of disc space will give you 3.5 days to fix an issue. Great!
I'm no expert but I'll answer anyway. ;)

Various circumstances can prevent OE Replication from streaming AI data; network dropout, loss of synchronization, death of replagent, bugs, cosmic rays, bad karma, etc. Once that happens, AI extents will lock, one by one, and thus the supply of empty AI extents will diminish with each AI extent switch. Once you exhaust the empty AI extents, you are in an unhappy place, with fewer options. So if you are using the AIMD (AI File Management Daemon, aka AI archiver*) with time-based switching, then your maximum time from happy to unhappy is ((( # of AI extents ) - 1 ) * aiarcinterval ) minutes. And this can be exacerbated by other factors; AI extent switches are also caused by probkup (offline or online), by proquiet enable, and by rfutil -C aimage new.

So certainly one factor to consider in this decision is how much time you will need from problem detection to problem resolution. This, in turn, is influenced by your monitoring/alerting of AI and replication status, and your staffing: is the database maintained by one person who has to sleep occasionally, or by a rotating team? The larger point here is that no one answer is the right answer for everyone. But I tend to lean toward a larger number now than in the past. Let's say a couple of dozen files as a starting point. But again, RPO (-aiarcinterval) can influence that a lot.

*Naming things is hard.
 
I totally agree with Rob but a few questions are still remained. The most of the times I see the voluntaristic choice of the options and I’m trying to collect the criteria to make the choice more “calculable”. I'm looking for a "formula".

Let’s assure we should keep the replication running. Otherwise, we could use the minimal number of the variable length AI extents.

how much time you will need from problem detection to problem resolution.
One of the factors is the disc space available for AI files. Raphael has enough disc space to create 300 AI extents. Would it be a correct decision? I don’t think so. The current average AI writes are just about 1 MB/sec. When the business will grow and AI files will be larger then a chance to get the “insufficient disk space during write” will grow as well. Conception of the variable length extents a bit contradicts to an idea to have the large number of the extents. To have only 3 AI extents would be too small. 300 extents is too large. Is 10 AI extents an optimal or voluntaristic choice?

your maximum time from happy to unhappy is ((( # of AI extents ) - 1 ) * aiarcinterval ) minutes.
We can maximize both values (# of AI extents as well as aiarcinterval). Hence the question - how to choose the optimal value of aiarcinterval. The larger interval the larger AI files the larger the time to archive them. 16 min - AI files are less then 1 GB. Max aiarcinterval is 86400 sec (24 hours) and AI files would be less then 90 GB. Would it be too extremal choice?

We can increase online any of these two values in case of an incident. This can be easily scripted but everyone seems to prefer not to make the changes even manually. Why?

Every medicine has the side effects. If there aren't any, it's not a medicine. I would like to compare to the possible negative side effects with the expected positive results.
 
Back
Top