Performance problem in permanent journel 1

[bunwong]

Hi,

We are planning to perform an incremental backup on a hugh table. Full backup won't work here due to the size. As a result, we have turned on the permanent after journal of the table and try to backup the journal instead.

However, after turning on the journal, it causes peroformance problem, every SQLs take double time to complete.

Did you encountered this situation? Any suggestion to solve this performance problem?

Thanks,

Bun

 

[dnoeth]

What kind of SQL are you talking about?

INSERT/UPDATE/DELETE will slow down, because the PJ has to be written. In worst case (e.g. single row INSERTs in a table without Sec. Indexes) this may double the IOs.

SELECTs shouldn't show any performance degradation.

Dieter

 

[bunwong]

Dear dnoeth,

I am talking Insert/Upadte/Delete. I have no problem on select.

Any work around for the incremental backup? Thanks,

Bun

 

[dnoeth]

The only way to make the permanent journaling faster is a LOCAL AFTER journal instead of the default.

BUT... if an AMP's VDisk is lost (a rank in your Raid is failing) this won't help you to recover the system. You could only restore to your last full backup.


Another option to avoid backups exceeding your batch window might be taking CLUSTER backups, i.e. only a subset of your AMPs is backed up each day. Maybe you should contact NCR support to help you with that problem

Dieter