dump database

Discussion:

dump database

(too old to reply)

unknown

2008-08-15 19:13:19 UTC

after looking at the backupserver dump log, found 8 min gap
between entries

<log DUMPED entries almost every minute>
...
...
Aug 15 11:01:49 2008: 14390038 kilobytes (15%) DUMPED.
Aug 15 11:02:43 2008: 15355324 kilobytes (16%) DUMPED.
Aug 15 11:11:47 2008: boss_history: 16320354 kilobytes (17%)
DUMPED.
Aug 15 11:12:41 2008: 17264760 kilobytes (18%) DUMPED.

8 minutes GAP (?)

Aug 15 11:58:34 2008: 62293688 kilobytes (64%) DUMPED.
Aug 15 11:59:38 2008: 63252512 kilobytes (65%) DUMPED.
Aug 15 12:08:33 2008: 64211336 kilobytes (66%) DUMPED.
Aug 15 12:09:23 2008: 65170160 kilobytes (67%) DUMPED.

8 minutes GAP (?)

Aug 15 12:32:32 2008: 90089160 kilobytes (92%) DUMPED.
Aug 15 12:33:30 2008: 91031302 kilobytes (93%) DUMPED.
Aug 15 12:41:52 2008: 91983326 kilobytes (94%) DUMPED.

8 minutes GAP (?)

The dump shows thrice 8 min gap, rest of the time-entry in
log is for every minute. Why would there be a 8 Minute GAP?

Michael Peppler

2008-08-16 06:04:06 UTC

Permalink

Post by unknown
after looking at the backupserver dump log, found 8 min gap
between entries
<log DUMPED entries almost every minute>
...
...
Aug 15 11:01:49 2008: 14390038 kilobytes (15%) DUMPED.
Aug 15 11:02:43 2008: 15355324 kilobytes (16%) DUMPED.
Aug 15 11:11:47 2008: boss_history: 16320354 kilobytes (17%)
DUMPED.
Aug 15 11:12:41 2008: 17264760 kilobytes (18%) DUMPED.
8 minutes GAP (?)
Aug 15 11:58:34 2008: 62293688 kilobytes (64%) DUMPED.
Aug 15 11:59:38 2008: 63252512 kilobytes (65%) DUMPED.
Aug 15 12:08:33 2008: 64211336 kilobytes (66%) DUMPED.
Aug 15 12:09:23 2008: 65170160 kilobytes (67%) DUMPED.
8 minutes GAP (?)
Aug 15 12:32:32 2008: 90089160 kilobytes (92%) DUMPED.
Aug 15 12:33:30 2008: 91031302 kilobytes (93%) DUMPED.
Aug 15 12:41:52 2008: 91983326 kilobytes (94%) DUMPED.
8 minutes GAP (?)
The dump shows thrice 8 min gap, rest of the time-entry in
log is for every minute. Why would there be a 8 Minute GAP?

How is your system (at the OS level) behaving during that time?

Michael

unknown

2008-08-16 14:03:58 UTC

Permalink

Post by unknown

between 11:02 (16%) and 11:11 (17%) 8 Min gap

Post by unknown

Post by unknown
Aug 15 11:58:34 2008: 62293688 kilobytes (64%) DUMPED.
Aug 15 11:59:38 2008: 63252512 kilobytes (65%) DUMPED.
Aug 15 12:08:33 2008: 64211336 kilobytes (66%) DUMPED.
Aug 15 12:09:23 2008: 65170160 kilobytes (67%) DUMPED.
8 minutes GAP (?)

between 11:59 (65%) and 12:08 (66%) 8 Min gap

Post by unknown

Post by unknown
Aug 15 12:32:32 2008: 90089160 kilobytes (92%) DUMPED.
Aug 15 12:33:30 2008: 91031302 kilobytes (93%) DUMPED.
Aug 15 12:41:52 2008: 91983326 kilobytes (94%) DUMPED.
8 minutes GAP (?)

between 12:33 (93%) and 12:41 (94%) 8 Min gap

Post by unknown

Post by unknown
The dump shows thrice 8 min gap, rest of the time-entry
in log is for every minute. Why would there be a 8

Minute GAP?
How is your system (at the OS level) behaving during that
time?
Michael

I dumped again, the gaps seems re-apper to be consistent.
Its new server 15.0.2 ESD5, no activity on the OS.

During the normal(no-gaps) dump, prstat shows sybmultibuf is
using 2 - 5 % cpu, dataserver (2engines are .3 - .5 % used);
When the BACKUPServer log reports gap, prstat shows
dataserver at the same .3 - .5% but no sign of sybmultibuf
utilising cpu (!). sar i/o output is normal no high waits or
system activity.

its like sybmultibuf is working in factory shift and has to
take break (dissaper from prstat when the backupserver
indicated huge gap in dumped %) i am losing around 1/2 hour
in dump time. Any thoughts on why sybmultibuf is acting
weird or this is just a normal behaviour ?

Jeff Tallman

2008-08-29 17:58:25 UTC

Permalink

Sybmultibuf reads directly from the disk devices - one possibility is
that the device is busy....I guess the real question though is whether
the gaps you noticed happen at the same TIME or at the same LOCATION
within the dump (i.e. ### kilobytes DUMPED). If it occurs at the same
time (regardless of KB) then likely cause is another process tying up
the disks. If it occurs at the same place, then the likely cause is
that (for whatever reason) you may have a range of empty pages (and ASE
just dumps the allocation pages for those) and then you hit the full
pages...latter is not a likely scenario.... Alternative, if the dump
seems to block every ### KB, then you are hitting some cache limit in
the dump device.

...it is interesting, though, that the gaps you point out seem to be
located nearly the 30 minute boundaries ...within a few minutes at
least. Makes me a bit suspicious of #1 - a concurrent process that
detracts either from the reading of the db devices or writes to the dump
device.

Post by unknown

between 11:02 (16%) and 11:11 (17%) 8 Min gap

Post by unknown

between 11:59 (65%) and 12:08 (66%) 8 Min gap

Post by unknown

between 12:33 (93%) and 12:41 (94%) 8 Min gap

Post by unknown

Post by unknown
The dump shows thrice 8 min gap, rest of the time-entry
in log is for every minute. Why would there be a 8

Minute GAP?
How is your system (at the OS level) behaving during that
time?
Michael

I dumped again, the gaps seems re-apper to be consistent.
Its new server 15.0.2 ESD5, no activity on the OS.
During the normal(no-gaps) dump, prstat shows sybmultibuf is
using 2 - 5 % cpu, dataserver (2engines are .3 - .5 % used);
When the BACKUPServer log reports gap, prstat shows
dataserver at the same .3 - .5% but no sign of sybmultibuf
utilising cpu (!). sar i/o output is normal no high waits or
system activity.
its like sybmultibuf is working in factory shift and has to
take break (dissaper from prstat when the backupserver
indicated huge gap in dumped %) i am losing around 1/2 hour
in dump time. Any thoughts on why sybmultibuf is acting
weird or this is just a normal behaviour ?