Blocked Check points during onload
Hello to you all. I couldn't find anything in the manuals about how to
correct blocked checkpoints so I have a quick question on what I am doing
how to handle them.
I use onunload/onload to copy our production db and restore as a test in a
separate dbspace. I schedule this as a cron during off hours or on the
weekend with acceptable results.
However, on occasions we need a fresh copy during production times.
Onunload works great. The last couple times I used onload I had some
problems. Everything works fine until 1 hour into the onload process and I
have a checkpoint blocked msg during my onstat -* scans. I am unable to
force a checkpoint from onmonitor or onmode (it was thinking about it for
over ten minutes so I killed it instead of having hundred's of users
wondering why the system is effectively down).
Questions: how to prevent the blocked checkpoints during this process and is
there a better way to copy the db during production times?
tia
Blocked checkpoints??? What's a blocked checkpoint? Now there is such a thing
as Blocked LBU, but that doesn't have to do with a checkpoint. That message
pertains to logical logs that are full and in need of backing up. This actually
sounds like the case that's happening. When the all the logs become full,
unless you've set your onconfig LBU_PRESERVE parameter to 1, your system
essentially hangs waiting for you to backup the logical logs. If that's the
message you're getting, simply back up the logical logs using the normal method
you use (i.e. ontape or onbar) and you should be fine. Best of luck.
adiosadios wrote:
> Hello to you all. I couldn't find anything in the manuals about how to
> correct blocked checkpoints so I have a quick question on what I am doing
> how to handle them.
>
> I use onunload/onload to copy our production db and restore as a test in a
> separate dbspace. I schedule this as a cron during off hours or on the
> weekend with acceptable results.
>
> However, on occasions we need a fresh copy during production times.
> Onunload works great. The last couple times I used onload I had some
> problems. Everything works fine until 1 hour into the onload process and I
> have a checkpoint blocked msg during my onstat -* scans. I am unable to
> force a checkpoint from onmonitor or onmode (it was thinking about it for
> over ten minutes so I killed it instead of having hundred's of users
> wondering why the system is effectively down).
>
> Questions: how to prevent the blocked checkpoints during this process and is
> there a better way to copy the db during production times?
>
> tia
--
Phillip Tien
Database Administrator
Whole Foods Market, Inc.
Blocked checkpoint means the system is doing a checkpoint. If you are
writing out lots of data, one might expect your checkpoints to be long.
Posting the output from onstat -c might allow us to give some
suggestions on how you might shorten your checkpoints.
Will
In article <95msbe$t5t$1@news.xmission.com>,
"adiosadios" <adiosadios@crosswinds.net> wrote:
>
> Hello to you all. I couldn't find anything in the manuals about how
to
> correct blocked checkpoints so I have a quick question on what I am
doing
> how to handle them.
>
> I use onunload/onload to copy our production db and restore as a test
in a
> separate dbspace. I schedule this as a cron during off hours or on
the
> weekend with acceptable results.
>
> However, on occasions we need a fresh copy during production times.
> Onunload works great. The last couple times I used onload I had some
> problems. Everything works fine until 1 hour into the onload process
and I
> have a checkpoint blocked msg during my onstat -* scans. I am unable
to
> force a checkpoint from onmonitor or onmode (it was thinking about it
for
> over ten minutes so I killed it instead of having hundred's of users
> wondering why the system is effectively down).
>
> Questions: how to prevent the blocked checkpoints during this process
and is
> there a better way to copy the db during production times?
>
> tia
>
>
Sent via Deja.com
http://www.deja.com/
adiosadios wrote in message <95msbe$t5t$1@news.xmission.com>...
>
<things;->
Have you found a solution to this?
Otherwise, my 1st questions would be:
how big is your database? (allocated + used) output of onstat -d will do
fine.
how big is your physical log?
how big and how many logical logs have you got?
The engine freezes for a few reasons, and one is not being able to do
checkpoints until archives or other things are completed. The general
solution to that is to have "sufficienty large" logs of the physical and
logical types. Body and mind...
output of
onstat -d
onstat -c
onstat -l
would be useful to show details here.