Oracle FAQ Your Portal to the Oracle Knowledge Grid

Home -> Community -> Mailing Lists -> Oracle-L -> Checkpoint process consuming a full CPU for the last 16 hours

Checkpoint process consuming a full CPU for the last 16 hours

From: <>
Date: Fri, 03 Aug 2007 09:28:37 +0200
Message-id: <>


I have a production DB that has been restarted on last saturday, July 28th at 20h15 (by a senior collegue who's on vacation now). When I look at the top 10 processes in UNIX, a process called ora_ckpt_ORAP9 keeps popping up and it is running since July 28th. Is this a process that is supposed to run since the start of the DB ?

I also seems to be consuming 1 out of 8 CPU's since I did the following:
- adjusted the undo retention (Online) from 3600 to 2700 to see if this was
reflected in the initDB.ora file (it wasn't, so all dynamic parameters that were adjusted before the reboot were reset)
- adjusted the shared pool size from 1000M to 600M and the undo retention
from 3600 to 1800.

The reason I did this, is to return to a previous situation to investigate a performance issue.
Is this a normal reaction of the system ?

In the mean time I discussed this with an overseas collegue and learned that it is indeed the initDB.ora file that is taken into account because there is no spfile.
But he doesn't know either if the checkpoint process should be running that intensely.

Should I have restarted the DB for these changes ? Should I still do this now to get things back to normal again ?

Jürgen Mortier

AMI Semiconductor - "Silicon Solutions for the Real World" NOTICE:
This electronic message contains information that may be confidential or privileged. The information is intended for the use of the individual or entity named above. If you are not the intended recipient, please be aware that any disclosure, copying, distribution or use of the contents of this information is prohibited. If you received this electronic message in error, please notify the sender and delete the copy you received.

Received on Fri Aug 03 2007 - 02:28:37 CDT

Original text of this message