Onbar uses sqlexec threads or???

Hi all, Onbar questions regarding the buffer cache..... (I'm using IDS 7.31.FD6X3 on Sun Solaris 64 bit, with Veritas Netbackup for Onbar) My onconfig : BUFFERS 800000 BAR_MAX_BACKUP 12 BAR_RETRY 2 BAR_NB_XPORT_COUNT 10 BAR_XFER_BUF_SIZE 31 Would this be ? : 800,000 buffers * 2048 byte pages (sun solaris 2.7) = 1.6 GB when a backup runs, it will allocate 10 of the 800,000 buffers for data transport, and these buffers will be 31 KB (therefore 10 * 31 kb = 310 kb)? So when a backup runs, I am using 310 KB of the 1.6 GB to handle the backup?, (310 KB out of 1.6 GB is a drop in the bucket) Am I thinking correctly on this? If onbar is just another unix process, does it use sqlexec threads as worker bees for the backup? I am wondering because we are on SAP. Last Saturday I did an Informix upgrade (731fc6x2 to 731fd6x3) and the SAP admins did an SAP kernel patch. That night, the onbar backup started, and the checkpoints went crazy.... From an average of 10 seconds to an average of 200+ seconds. Also the foreground writes were shooting through the roof. We discovered a goof up in the SAP kernel patch, that we hope, once fixed will fix the issue. None of my other similarly upgraded systems are performing badly (but the SAP kernel patch was not goofed up on those systems). I know sqlexecs do foreground writes, and I know they are bad. (again, I am optimistic the SAP kernel goof will fix that). But I got to wondering if onbar could also have been doing some foreground writes... .. So I'm thinking if onbar does not use sqlexec threads, it would not have been involved in the foreground writing... Therefore the foreground write mess and badly performing use of the Informix buffer cache was predominantly caused by the sapr3 (SAP user) connections, not the onbar connections.... It may be a long shot, but it's all I got for now.... If anyone can help me understand this, I'd appreciate it, Thanks, NJ ----------------------------------------- ============================================================ The information contained in this message may be privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any reproduction, dissemination or distribution of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. Thank you. Tellabs ============================================================

Did you update the statistics after upgrade ? It makes difference, if you are not update statistics of the database. Ravi Yarlagadda -----Original Message----- From: Sebastian, .... [mailto:NormaJean.Sebastian@tellabs.com] Sent: Tuesday, July 20, 2004 3:55 PM To: ids@iiug.org Subject: Onbar uses sqlexec threads or??? [3266] Hi all, Onbar questions regarding the buffer cache..... (I'm using IDS 7.31.FD6X3 on Sun Solaris 64 bit, with Veritas Netbackup for Onbar) My onconfig : BUFFERS 800000 BAR_MAX_BACKUP 12 BAR_RETRY 2 BAR_NB_XPORT_COUNT 10 BAR_XFER_BUF_SIZE 31 Would this be ? : 800,000 buffers * 2048 byte pages (sun solaris 2.7) = 1.6 GB when a backup runs, it will allocate 10 of the 800,000 buffers for data transport, and these buffers will be 31 KB (therefore 10 * 31 kb = 310 kb)? So when a backup runs, I am using 310 KB of the 1.6 GB to handle the backup?, (310 KB out of 1.6 GB is a drop in the bucket) Am I thinking correctly on this? If onbar is just another unix process, does it use sqlexec threads as worker bees for the backup? I am wondering because we are on SAP. Last Saturday I did an Informix upgrade (731fc6x2 to 731fd6x3) and the SAP admins did an SAP kernel patch. That night, the onbar backup started, and the checkpoints went crazy.... From an average of 10 seconds to an average of 200+ seconds. Also the foreground writes were shooting through the roof. We discovered a goof up in the SAP kernel patch, that we hope, once fixed will fix the issue. None of my other similarly upgraded systems are performing badly (but the SAP kernel patch was not goofed up on those systems). I know sqlexecs do foreground writes, and I know they are bad. (again, I am optimistic the SAP kernel goof will fix that). But I got to wondering if onbar could also have been doing some foreground writes... .. So I'm thinking if onbar does not use sqlexec threads, it would not have been involved in the foreground writing... Therefore the foreground write mess and badly performing use of the Informix buffer cache was predominantly caused by the sapr3 (SAP user) connections, not the onbar connections.... It may be a long shot, but it's all I got for now.... If anyone can help me understand this, I'd appreciate it, Thanks, NJ ----------------------------------------- ============================================================ The information contained in this message may be privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any reproduction, dissemination or distribution of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. Thank you. Tellabs ============================================================

If you are doing a parallel backup, onbar_d processes are started on Unix to backup each dbspace. Each onbar_d process connects to server and starts an ontape thread in the server. The backend thread (ontape) does not perform much write in the server and thus will not cause any foreground write. It does update some sysutil tables but that happens after backup is completed. Each ontape thread in server creates its own transport buffers specified by BAR_NB_XPORT_COUNT and BAR_XFER_BUF_SIZE. Ontape threads do not use regular buffers.