Clarification on ONBAR Backup performance issue..

Posted in 2003

Rajasekaran, Rajesh — Thu, 28 Aug 2003 08:25:55 -0500 — source: Usenet: comp.databases.informix

This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C36D67.E91BD400 Content-Type: text/plain; charset="iso-8859-1" Hello all, I would like to clarify regarding the performance degradation on our backups. Our weekly level0 backup normally completes in 10 hrs for 330gb database and our daily incremental backup takes 1-1.5 hrs. We take the whole system serial backup using ONBAR-VERITAS hook. Right now, we are not using parallel backups for our environment. We have the Sun fire V880 with Solaris 9/ SAP R3/IDS 7.31UD2XG. We noticed that for the past 2 level0, it has gone to 22 hrs and surprisingly our level 1 now takes 6 hrs for the past 2 days. After some investigation, this is what i could make out. We have one dbspace "psapbtab" with 153 GB with all 2 GB chunks. I agree the dbspace is deeper in size,which will hamper the bkup performance etc. but until 2 weeks back i got the whole psapbtab under 4.5 hrs. Level1 for this dbspace used to take 35m-1hr and now it takes 4-5 hrs. This means that the problem lies with this dbspace only. I checked for the "old pages" bug running during the backup and i couldnt find that "arc_very_old_pages()" with "onstat -g stk <tid> of arcbackup1" at all. Nothing changed from the VERITAS side as well. Also, we didnt re-start our systems for some time now. I see a total of 3 additional virtual portion shared memory segments on the "onstat -g seg" got created. Here is our ONCONFIG onbar related parameters. BAR_ACT_LOG /informix/PRD/bar_act.log BAR_MAX_BACKUP 0 BAR_RETRY 1 #BAR_NB_XPORT_COUNT 10 BAR_NB_XPORT_COUNT 100 BAR_XFER_BUF_SIZE 31Question 1) What could be the cause for the sudden performance degradation ? 2) Does the additional segments created in different physical location on the shared memory cause the problem ? I am just wondering if this could be the case, it might have degraded the whole database. Please let me know if you need further inputs to pass on your comments/suggestions. Your suggestions are greatly appreciated. Rajesh Rajasekaran Informix Database Administrator Forest Pharmaceuticals Inc. (314) 493-7073 rrajasekaran@forestpharm.com ------_=_NextPart_001_01C36D67.E91BD400 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> <HTML> <HEAD> <META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; = charset=3Diso-8859-1"> <META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version = 5.5.2653.12"> <TITLE>Clarification on ONBAR Backup performance issue..</TITLE> </HEAD> <BODY> Hello all,      I would like to clarify regarding the = performance degradation on our backups.    Our weekly level0 backup normally completes in 10 = hrs for 330gb database and our daily incremental backup takes 1-1.5 = hrs. We take the whole system serial backup using ONBAR-VERITAS hook. = Right now, we are not using parallel backups for our environment. We = have the Sun fire V880 with Solaris 9/ SAP R3/IDS 7.31UD2XG. We noticed = that for the past 2 level0, it has gone to 22 hrs and surprisingly our = level 1 now takes 6 hrs for the past 2 days. After some investigation, this is what i could make = out. We have one dbspace "psapbtab" with 153 GB with all 2 GB = chunks. I agree the dbspace is deeper in size,which will hamper the = bkup performance etc. but until 2 weeks back i got the whole psapbtab = under 4.5 hrs. Level1 for this dbspace used to take 35m-1hr and now it = takes 4-5 hrs. This means that the problem lies with this dbspace = only.  I checked for the "old pages" bug running during = the backup and i couldnt find that "arc_very_old_pages()" = with "onstat -g stk <tid> of arcbackup1" at all.  = Nothing changed from the VERITAS side as well. Also, we didnt re-start our systems for some time = now. I see a total of 3 additional virtual portion shared memory = segments on the "onstat -g seg" got created.   Here = is our ONCONFIG onbar related parameters. BAR_ACT_LOG     = /informix/PRD/bar_act.log BAR_MAX_BACKUP  0 BAR_RETRY       = 1 #BAR_NB_XPORT_COUNT 10 BAR_NB_XPORT_COUNT 100 BAR_XFER_BUF_SIZE 31 Question 1) What could be the cause for the sudden performance = degradation  ? 2) Does the additional segments created in different = physical location on the shared memory cause the problem ? I am just = wondering if this could be the case, it might have degraded the whole = database.  Please let me know if you need further inputs = to pass on your comments/suggestions. Your suggestions are greatly appreciated. Rajesh Rajasekaran Informix Database Administrator Forest Pharmaceuticals Inc. (314) 493-7073 rrajasekaran@forestpharm.com </BODY> </HTML> ------_=_NextPart_001_01C36D67.E91BD400-- sending to informix-list

Clarification on ONBAR Backup performance issue..

Related threads

Your privacy choices