Not using after-imaging

Why Progress does not do what is done in SQL Server and Oracle, i.e. enabled after-images ( called "Archiving Mode" in Oracle and "Recovery Model" in SQL) by default? And DBA would have to explicitly disable it then.

Fair question, Dmitri.  I'm sure many (most? all?) software shops including PSC would say that if they had it all to do over again, with the benefit of hindsight, they'd do many things differently.

You could ask a similar question about default database security, on the ABL side.  It is very developer-centric and very much not production-centric.  

But big changes don't come for free.  Making AI on-by-default would be disruptive to many non-production environments and business processes.  And fixing those at scale, even if it were easy to do on a single DB or process or script, would have a non-trivial cost for customers and partners.  It would cost PSC a fair bit too: changing code, docs, KB articles, training materials, DBs, etc.  

Personally I'd rather see them invest in other areas.  I'm sure they have no shortage of product roadmap items to get to, just as I'm sure we can all name several features we've wanted and requested for years that we're still waiting for them to deliver.  

In short, I agree with Tom: always use AI in production.  I'm okay with having to enable it manually.

The only thing is that AI (in OpenEdge) cost performance.

I just had my experience that I ran the same code in two database with same schema, the difference is that one has AI the other not, both are one the same virtual server, same virtual disk.

It's a full single table update (for each table).

After ~ 1h runtime the database without AI updated the double amount of records.

Yes, a physical server could be better with separate controllers, disk, ...

But why should PSC slow down the performance by default?

> But why should PSC slow down the performance by default?

Should PSC boost the performance by setting the -i option as default? ;-)

> I just had my experience that I ran the same code in two databases

Did you run the tests in single-user mode?

You are describing one of the extremely rare special cases where one might reasonably decide to temporarily disable after imaging in order to complete some special processing.  That is not a good reason for the overwhelmingly vast majority of users to be risking their data.

As George points out -- you could also use -i for your particular case.  But that is certainly not something that everyone should always do either.  You would also probably find that your process runs faster in single user mode.

"why PSC should slow down performance by default?"

0) In almost all real-world OLTP scenarios after-imaging adds no noticeable performance cost.  Your example is not at all normal or typical.

1) Progress has to balance performance against robustness -- performance does not always win.  Nor should it.  Correct results and data integrity are not negotiable.  (Unless you are more interested in racing sailboats.)

One issue I've found with inexperienced people and setting up DBs is that they found AI very tricky to set up and manage in older versions, particularly prior to the AI Archiver. As a result it's put them off due to perceived complexity. The AI Archiver certainly helps with this but I think it could be taken further.

For example a process that removes aged archive files would be brilliant so long as you can specify what aged really means.

And I know this will irk the likes of Tom, but the reality is that a lot of people consider Windows a suitable OS to run a DB server from. As a result they are not used to loads of command line activity. I've heard over and over again that a simpler way of setting up DB stuff such as After Imaging is desirable.

If they want "simple" then they really ought to reconsider their command line paranoia ;)

I agree 100% that a built-in purge option is the logical next step for the ai management daemon.  Such a feature would make it dead-simple for a hands-off out of the box ai implementation to be successful.

There should also be a utility along the lines of "dbman" specifically to manage the ai management daemon.  I suppose that a corresponding GUI interface might be built around that.  But I, personally, am unlikely to ever use such a GUI.

Fixing the ridiculous file names would also be useful.

> On Jun 9, 2016, at 8:50 AM, James Palmer wrote:

>

> For example a process that removes aged archive files would be brilliant so long as you can specify what aged really means.

find -f /archivepath -x -mtime +30 exec rm -f {} ";"

fixing the ai filenames is a complete waste of time. not in the least useful, though i guess it would please you. :)

Don't you have scripts for that Tom? :-)

I was not a huge fan of the AIMGT generated file names at first.. but when I switched my backup files to the same naming convention it made life much easier.

Now I can easily tell from a backup file where it is in the AI chain and which AI files need to be applied in which order. Automated restores and AI applies are pretty trivial once you embrace the madness.

I would like to see probkup integrated with the AIMGT process to make the process even simpler. Tell it when to run your backups and let it name the backup file(s) for you.

It could also handle cleanup with hopefully a few hooks to let AIMGT know that you have safely copied the files before it decides to remove them.

Well, yeah, of course.  But every now and then I land on a machine that doesn't have said scripts and which is locked up behind all sorts of firewalls and crap at least one layer of which interferes with copy & paste...

Having said that -- automating the purge interval is 1000% more important.

And I like the idea of automating the backup too.