Question Enable Large Files

ew25950

New Member
Hello. I wanted to fact check something here with the experts please. We have a software vendor that gives good support for their software, but I do like to check on what they are telling me from time to time.

We have some DB extents that are approaching the 2GB limit so we have to follow the procedure to add others where needed during our next downtime. The vendor mentioned that Progress does not recommend enabling Largefiles. I'm thinking it might not be an option at all if they didn't intend for it to be used. What's your thoughts on enabling Largefiles?

We are on:
OpenEdge Release 10.2B05
Windows Server 2012R2

I know 10.2B and 2012R2 are old, but those are both out of my control at the moment.
 

Rob Fitzpatrick

ProgressTalk.com Sponsor
The vendor mentioned that Progress does not recommend enabling Largefiles.
I've never heard that; maybe it's antiquated advice from days gone by. I don't know of anyone, of any reputation, who makes that recommendation. I enable large files on all of my own and my customers' databases. I don't know of any reason not to when using Enterprise RDBMS.

Do they offer any recent written evidence of this claim? Even if it were considered a best practice at one time (and I'm not saying that it was), many of those have a tendency to become obsolete or even worst practices over time.

The cynical voice in my head says that if this vendor is keeping you on 10.2B in 2020 (and SP05 at that), with an application that was installed in 2012 at the earliest, they may not be an exemplar of knowing and following OpenEdge best practices.

I know 10.2B and 2012R2 are old, but those are both out of my control at the moment.
10.2B is indeed old and now retired. If you can't upgrade to a mature release like 11.7 or 12.x, is there any reason why you can't at least install 10.2B08?
 

Cringer

ProgressTalk.com Moderator
Staff member
The only "Best Practise" I can think of is the advice that you should stick to fixed extents. If you're sticking to fixed extents, then why bother with large files?
But fixed extents really aren't much better, if at all.
Te only consideration for enabling large files is, that if you are on OE Replication, you need to enable it on source and target at the same time.
 

Rob Fitzpatrick

ProgressTalk.com Sponsor
The only "Best Practise" I can think of is the advice that you should stick to fixed extents. If you're sticking to fixed extents, then why bother with large files?
Sticking to fixed extents doesn't have to mean sticking to tiny 2 GB extents. If a table is in its own area and is 50 GB, would you rather have two extents or 25? More extents means longer and harder-to-read file listings and structure files, and more importantly, more file handles in use as every shared-memory connector opens every database file.

There is a case to be made for having *some* fixed extents, e.g. if you have a very fast-growing table in its own area, to prevent a single extent from growing to be dozens or hundreds of GB and becoming a maintenance headache. But, in my opinion, outside of special cases like that (and even then only if you're watching the area like a hawk for utilization and adding a new extent as necessary) every area should have its final (or only) extent as variable. DBAs have better things to do with their time than waiting for extents to fill and adding new ones, or sweating the ticking time bomb of areas with no variable extent.

I tend to work with smaller databases, but my structures are almost exclusively all-variable, one extent per area. If an extent gets into the tens of GB, I'll cap it and add a variable. When I started at my company, we used fixed extents and no large file support. Customer DBs going down and requiring emergency maintenance because of a filled extent was a semi-regular occurrence. I changed it to my current approach and that problem hasn't happened in years.
 

Cringer

ProgressTalk.com Moderator
Staff member
Sticking to fixed extents doesn't have to mean sticking to tiny 2 GB extents. If a table is in its own area and is 50 GB, would you rather have two extents or 25? More extents means longer and harder-to-read file listings and structure files, and more importantly, more file handles in use as every shared-memory connector opens every database file.
I wasn't saying it was a good idea, just that it's a possible thing a vendor might say!! ;)
 
If you will not use Enable Large file in the future,

Look in your procedure if you have a "prostrct add [DB] [the-new.st]", you could probably replace it by an "prostrct addonline [DB] [the-new.st]" which could be run outside of the downtime (on a open DB).
 

ew25950

New Member
Thanks for the replies. More or less what I expected. They don't offer a specific KB or article as evidence. I also have the same doubts of them being an example of best practices as they are still forcing 10.2B. They also don't advise or give any documentation on simple DB maintenance (dbanalys and such).

I've got to pick my battles with them and I'm not sure this one is worth the argument just yet. Supposedly they will announce a plan to move to Progress 12 this year.

Again, appreciate the replies.
 

Rob Fitzpatrick

ProgressTalk.com Sponsor
Supposedly they will announce a plan to move to Progress 12 this year.

Good luck!

Note that the current OpenEdge Life Cycle info and the Platform and Product Availability Guide are published here:
OpenEdge Product Availability Guides and Life Cycle Guide - Wiki - OpenEdge General - Progress Community

At recent conferences, Progress announced that they would be changing the life cycle of 12.x releases to an LTS model, as several OS vendors have done. They said it might work like this: releases like 12.0 and 12.1 would have shorter life spans, more targeted at developers/ISVs, then 12.2 would be targeted at client deployments and would have a longer support life span. Then there would be a few short-term releases followed by another long-term release. None of this is carved in stone; they're still working out the details. But it's good to be aware of the upcoming changes so you can ask informed questions when the time comes.
 
With Progress 12, all DB have LARGE FILE ENABLED,
you cannot create a Db without Enable Large File, and i you do convXX12 , it will active the Enable Large File.

If you go To OE12 , you win this battle ...


If they do not want Enable large File, they must define the last extend of your area as variable with a limit size
( for 2 Gb this is somethings like d "Areaname":99,16;8 . v 2032192).
 

TomBascom

Curmudgeon
They might provide good application support but when it comes to the database they obviously have no clue and their “advice” should be ignored.

You should engage a competent 3rd party to review your configuration. If they are feeding you bologna as above then it is also likely that you have deeper reliability and data integrity risks.
 

TomCat

New Member
I am not going to repeat the answers you have already had - enable large files, it's a no brainer. However, I would suggest you install the latest service pack (10.2B08) - there were fixes and features galore put into 10.2B06 so getting to that latest would make a lot of sense.
 
Top