After-imaging use and its cost

Posted by ericg on 25-Mar-2013 16:58

We do nightly backups but I am wondering about the added cost of enabling after-imaging in terms of affecting the performance of the DB and OS? Is there a calculation out there?

All Replies

Posted by jmls on 25-Mar-2013 18:23

We haven't noticed a any change. We switch ai every 120s . Db is

160GB, growing by 75000 records per day

Posted by Rob Fitzpatrick on 26-Mar-2013 06:24

Do you wonder about the cost of having to explain to executives that they lost 24 hours of business data because the last backup ran at midnight (and we assume it's good...) and the DB got hosed at 23:59 the next day?  Especially after they talk to a consultant and learn that AI exists and you weren't using it?

Whether there is application "cost" depends on how you define it.  Is it transaction throughput?  EDI response time?  Latency in your application?  Whatever it means to you, run some tests in your non-production environment, duplicating production configuration to the extent that you can, and see if you can meansure the cost of running with AI versus without.  Assuming reasonable configuration, I doubt it will be a meaningful difference, if it is even measurable.

Gus Björklund and Tom Bascom ran a performance-tuning workshop at last year's PUG Challenge Americas conference, and covered this topic.  The end result, using the ATM benchmark, is that there was no negative performance impact to enabling AI.  But as mentioned there is a big potential business impact to not enabling it.

Regarding the OS, why do you think AI would affect its performance?

Posted by gus on 26-Mar-2013 09:08

There is a little performance overhead introduced by the after-image journalling feature. When properly configured, for a database with lots of update activity, I have measured (multiple times) a throughput reduction of about 4 percent. Other people's measurements have been consistent with this.

Other overhead resulting from the use of after-image journalling is:

  • disk space consumed by after-image extents. this varies considerably depending on the workload. archiving of filled extents to some other storage can be fully automated

  • disk space consumed by archived after-image data. again varies by workload. you can estimate the volume by using the promon program to look at how many bi log clusters are closed over some period of tiem, like a day or a week. The cluster size times the count is how many bytes of after-image data you get over the same time period. You can get the data from the R&D section, Activity, BI Log display page.

  • administration time required to pay attention to stuff to ensure that you don't run out of space, etc.
Posted by ericg on 26-Mar-2013 12:34

Yes Rob, good reason to enable AI. I think I will try it out on our Dev. server. My main concern was affect on DB performance and admin maintenance.

Are any notes on that performance-tuning workshop last year accessable?

Posted by ChUIMonster on 28-Mar-2013 11:30

No, the workshop presentations were not made available.

But this year's PUG Challenge is June 9-12 so you coud pop on in and ask questions

Like Gus I've done some testing -- basically I have only ever been able to detect a difference under very heavy load.  And even then the impact is fairly small.

Implementing after-imaging is very low risk with very high rewards.  Not implementing after-imaging is a potential retirement event.

This thread is closed