update statistics on sysutils
The poster asked how to speed up logical log backups with ON-Bar, having read IBM's tip to run UPDATE STATISTICS on the sysutils database, and wanted to know which columns to target and what else could help (noting BAR_MAX_BACKUP doesn't apply to log backups). TBP argued the bottleneck is usually elsewhere — logical log size/fill rate versus storage manager response time — and suggested using BAR_DEBUG/BAR_DEBUG_PATH (kept below level 5) to time each stage; sysutils query time is normally minimal. When pressed, he agreed running update statistics does no harm and pointed to an IBM technote on doing it, but no specific column list or measured improvement was given.
Auto-generated by DrWatson from the posts below — may be imperfect; read the full thread.
I am reading about various things that could make backing up logical
logs faster using onbar. One of the things that IBM recommends is
running update statistics on sysutils database. So my question is:
1. What columns should the update stats run against.
2. Are there any other ways to improve the logical log backup. I guess
answer is no as I can't even use BAR_MAX_BACKUP for logical log backup
mohitanchlia@gmail.com wrote:
> I am reading about various things that could make backing up logical
> logs faster using onbar. One of the things that IBM recommends is
> running update statistics on sysutils database. So my question is:
>
> 1. What columns should the update stats run against.
> 2. Are there any other ways to improve the logical log backup. I guess
> answer is no as I can't even use BAR_MAX_BACKUP for logical log backup
>
Humm,
I think you may be looking at the problem from the wrong end.
1. How big are your logical logs?
2. How often do they "fill up" (i.e. review the "logical log complete" messages).
3. How long does it take to back up a log?
4. What storage manager are you using? (local / remote?)
5. How do you backup your logical logs (ALARMPROGRAM or manually?)
If you have small logical logs which complete in 10 seconds and it takes your storage manager 20 seconds to locate a tape and mount
it, then you will have problems :-/
However, if you have "larger" logical logs (say you want to have recovery capability to within 15 minutes) which fill in 15 minutes,
then even if it takes one minute for the storage manager to find somewhere to place it, you will not have problems.
HTH
On Sep 11, 1:28 am, "TBP (The Big Potato)" <T...@NotHere.Co.Uk> wrote:
> mohitanch...@gmail.com wrote:
> > I am reading about various things that could make backing up logical
> > logs faster using onbar. One of the things that IBM recommends is
> > running update statistics on sysutils database. So my question is:
>
> > 1. What columns should the update stats run against.
> > 2. Are there any other ways to improve the logical log backup. I guess
> > answer is no as I can't even use BAR_MAX_BACKUP for logical log backup
>
> Humm,
>
> I think you may be looking at the problem from the wrong end.
>
> 1. How big are your logical logs?
> 2. How often do they "fill up" (i.e. review the "logical log complete" messages).
> 3. How long does it take to back up a log?
> 4. What storage manager are you using? (local / remote?)
> 5. How do you backup your logical logs (ALARMPROGRAM or manually?)
>
> If you have small logical logs which complete in 10 seconds and it takes your storage manager 20 seconds to locate a tape and mount
> it, then you will have problems :-/
>
> However, if you have "larger" logical logs (say you want to have recovery capability to within 15 minutes) which fill in 15 minutes,
> then even if it takes one minute for the storage manager to find somewhere to place it, you will not have problems.
>
> HTH
I was actually referring to the "Tips" section of following URL:
http://publib.boulder.ibm.com/infocenter/idshelp/v10/index.jsp?topic=/com.ibm.perf.doc/perf370.htm
On Sep 11, 4:46 pm, mohitanch...@gmail.com wrote:
> On Sep 11, 1:28 am, "TBP (The Big Potato)" <T...@NotHere.Co.Uk> wrote:
>
>
>
> > mohitanch...@gmail.com wrote:
> > > I am reading about various things that could make backing up logical
> > > logs faster using onbar. One of the things that IBM recommends is
> > > running update statistics on sysutils database. So my question is:
>
> > > 1. What columns should the update stats run against.
> > > 2. Are there any other ways to improve the logical log backup. I guess
> > > answer is no as I can't even use BAR_MAX_BACKUP for logical log backup
>
> > Humm,
>
> > I think you may be looking at the problem from the wrong end.
>
> > 1. How big are your logical logs?
> > 2. How often do they "fill up" (i.e. review the "logical log complete" messages).
> > 3. How long does it take to back up a log?
> > 4. What storage manager are you using? (local / remote?)
> > 5. How do you backup your logical logs (ALARMPROGRAM or manually?)
>
> > If you have small logical logs which complete in 10 seconds and it takes your storage manager 20 seconds to locate a tape and mount
> > it, then you will have problems :-/
>
> > However, if you have "larger" logical logs (say you want to have recovery capability to within 15 minutes) which fill in 15 minutes,
> > then even if it takes one minute for the storage manager to find somewhere to place it, you will not have problems.
>
> > HTH
>
> I was actually referring to the "Tips" section of following URL:
>
> http://publib.boulder.ibm.com/infocenter/idshelp/v10/index.jsp?topic=...
That just refers to "speeding up the queries / updates" that are run
by the onbar(_d) process against the sysutils.
Generally this bit of the run time is minimal (you can set BAR_DEBUG
and BAR_DEBUG_PATH to get more activity details from which you can
probably determine activity duration (e.g. storage manager response,
ixbar processing, sysutils updates etc. etc.) - keep BAR_DEBUG below 5
if you want to keep performance from going REALLY bad.
On Sep 12, 8:30 am, TBP <TheBigPota...@Nothere.Co.Uk> wrote:
> On Sep 11, 4:46 pm, mohitanch...@gmail.com wrote:
>
>
>
> > On Sep 11, 1:28 am, "TBP (The Big Potato)" <T...@NotHere.Co.Uk> wrote:
>
> > > mohitanch...@gmail.com wrote:
> > > > I am reading about various things that could make backing up logical
> > > > logs faster using onbar. One of the things that IBM recommends is
> > > > running update statistics on sysutils database. So my question is:
>
> > > > 1. What columns should the update stats run against.
> > > > 2. Are there any other ways to improve the logical log backup. I guess
> > > > answer is no as I can't even use BAR_MAX_BACKUP for logical log backup
>
> > > Humm,
>
> > > I think you may be looking at the problem from the wrong end.
>
> > > 1. How big are your logical logs?
> > > 2. How often do they "fill up" (i.e. review the "logical log complete" messages).
> > > 3. How long does it take to back up a log?
> > > 4. What storage manager are you using? (local / remote?)
> > > 5. How do you backup your logical logs (ALARMPROGRAM or manually?)
>
> > > If you have small logical logs which complete in 10 seconds and it takes your storage manager 20 seconds to locate a tape and mount
> > > it, then you will have problems :-/
>
> > > However, if you have "larger" logical logs (say you want to have recovery capability to within 15 minutes) which fill in 15 minutes,
> > > then even if it takes one minute for the storage manager to find somewhere to place it, you will not have problems.
>
> > > HTH
>
> > I was actually referring to the "Tips" section of following URL:
>
> >http://publib.boulder.ibm.com/infocenter/idshelp/v10/index.jsp?topic=...
>
> That just refers to "speeding up the queries / updates" that are run
> by the onbar(_d) process against the sysutils.
>
> Generally this bit of the run time is minimal (you can set BAR_DEBUG
> and BAR_DEBUG_PATH to get more activity details from which you can
> probably determine activity duration (e.g. storage manager response,
> ixbar processing, sysutils updates etc. etc.) - keep BAR_DEBUG below 5
> if you want to keep performance from going REALLY bad.
Nevertheless do you think we should run update stats on sysutils. I
think it probably be better then not doing it.
mohitanchlia@gmail.com wrote:
> On Sep 12, 8:30 am, TBP <TheBigPota...@Nothere.Co.Uk> wrote:
>
>>On Sep 11, 4:46 pm, mohitanch...@gmail.com wrote:
>>
>>
>>
>>
>>>On Sep 11, 1:28 am, "TBP (The Big Potato)" <T...@NotHere.Co.Uk> wrote:
>>
>>>>mohitanch...@gmail.com wrote:
>>>>
>>>>>I am reading about various things that could make backing up logical
>>>>>logs faster using onbar. One of the things that IBM recommends is
>>>>>running update statistics on sysutils database. So my question is:
>>
>>>>>1. What columns should the update stats run against.
>>>>>2. Are there any other ways to improve the logical log backup. I guess
>>>>>answer is no as I can't even use BAR_MAX_BACKUP for logical log backup
>>
...
<snip>
>
>
> Nevertheless do you think we should run update stats on sysutils. I
> think it probably be better then not doing it.
>
Sure, try this (short and sweet) :
http://www-1.ibm.com/support/docview.wss?rs=630&context=SSGU8G&context=SSHPYE&q1=update+statistics+performance&uid=swg21137764&loc=en_US&cs=utf-8&lang=en