Errors in DB13 when running checkDB

[Former Member]

Hello Experts,

When I run checkdb, it is giving the following error

BR0252W Function remove() failed for 'D:\oracle\BID\102\database\sap.ora' at location BrInitOraCreate-1

BR0253W errno 13: Permission denied

BR0976W Database message alert - level: WARNING, line: 568262, time: 2006-08-24 22.41.11, message:

Checkpoint not complete

Can anyone please advice on this issue.

[Former Member]

Hi ,

This may be caused by oracle 10g new feature self tune checkpoint.

Pls refer to notes:1068186

[Former Member]

>> BR0252W Function remove() failed for 'D:\oracle\BID\102\database\sap.ora' at location BrInitOraCreate-1

>> BR0253W errno 13: Permission denied

Check the Security Settings of 'D:\oracle\BID\102\database' directory using Windows Explorer and ensure that SAP_<SAPSID>_GOBALADMIN has full acces to this directory.

regards

Peter

[Former Member]

Hi Peter

I encountered the same problem as Shibli. I followed your advice and resolved the problem. Thanks.

Regards

YongQiang

[Former Member]

Hello

My Oracle database is 10.2.0 and SAP version is NW2004s. I am having errors in alert.log file

Thread 1 cannot allocate new log, sequence 3959

Checkpoint not complete

Sun Aug 27 01:38:12 2006

I have changed the parameter log_buffer from 14274560 to 1048576 following the SAP Note 830576. I changed the pfile and created a spfile from this pfile. Now the pfile and spfile reflect the parameter log_buffer as 1048576.

But surprisingly, when I say

SQL> show parameter log_buffer

NAME TYPE VALUE

log_buffer integer 14274560

Even after pfile and spfile reflecting 1048576 value for log_buffer, the database is showing this old value. Kindly let me know how to change the log_buffer parameter.

[Former Member]

After you created the spfile file, did you bounce the Oracle database?

I believe the log_buffer parameter is not dynamic.

[Former Member]

I shutdown the Oracle instance. then

$sqlplus "/ as sysdba"

SQL> create spfile from pfile;

SQL> startup

SQL> show parameter log_buffer

Here it is showing the same old value. The pfile and spfile reflect the new value.

[lbreddemann]

Hi Shibli,

the size of the log_buffer has only little to do with the

Thread 1 cannot allocate new log, sequence 3959

Checkpoint not complete

message in the alert log.

Usually this message is printed out, when the ARCHIVER is not quick enough so that all online redo logs have already been filled up with information but have not yet been archived. Therefore the online redo logs cannot be overwritten yet - thus the message is printed out and the DB will suspend further changes until new log information can be stored into the online redo logs.

Concerning the "self-changing" log_buffer parameter there is another topic in the list, where I explained it this:

With Oracle 10g this parameter can only be given a kind of lower border, not a specific value.

To make sure there is at least the well known 1MB buffer pool, SAP keeps up the recommendation to put this parameter into the instance profile.

Be aware, that if you're using DB13 DB Check you'll have to adapt the parameter check for log_buffer from "= 1M" to

">= 1M" which can be done in DB17.

KR Lars

[Former Member]

Hi,

A late response, concerning LOG_BUFFER in Ora 10, but anyway

I believe that you are encountering Oracle Bug: 4930608. This is outlined in MetaLink Note: 351857.1 as follows:

Symptoms:

In customer environment, no matter what value is specified for the log_buffer, the buffer size remains at @14mbs

In 10G R2 Reference manual, it states that this parameter can no longer be modified and its set by default to 512K or 128K * the cpu count in the server. The document is in error.

Cause:

@From Bug 4592994....

In 10G R2, Oracle combines fixed SGA area and redo buffer [log buffer] together. If there is a free space after Oracle puts the combined buffers into a granule, that space is added to the redo buffer. Thus you see redo buffer has more space as expected. This is an expected behavior.

"In 10.2 the log buffer is rounded up to use the rest of the granule...

@ From bug 4930608... @ The granule size can be found from the hidden parameter @ #"_ksmg_granule_size" and in your case is probably 16Mb".

Solution:

Log_buffer can no longer be modified and will be set by default by Oracle.

Unfortunately a fix is not presently available, however you can remove the warning from dbcheck through transaction

regards Steven

[Former Member]

I have 4 groups containing 2 members of logfiles and the size of each logfile is 52428800 bytes.

The logfile size is 52428800 bytes.

SQL> select group#,members,bytes,status from v$log;

GROUP# MEMBERS BYTES STATUS

-

---

-

---

-

---

-

---

1 2 52428800 INACTIVE

2 2 52428800 CURRENT

3 2 52428800 INACTIVE

4 2 52428800 INACTIVE

In alert.log file, it is giving the error

Thread 1 cannot allocate new log, sequence 3959

Checkpoint not complete

Please let me know what should be done.

[Former Member]

Hi

Performance can be dramatically improved by increasing the log sizes so that logs switch at the recommended interval of 15 to 30 minutes. Identify record the number of log switches per hour and increase the size of the log to allow Oracle to switch at the recommended rate of one switch per 15 to 30 minutes. For example, if the database log size is 1 megabyte and you are switching logs every 1 minute, you will need to increase the log size to 30 megabytes in size to allow it to switch every 30 minutes.

You either

a) checkpoint more aggresively (lower fast start mttr target, MORE redo log

files of smaller sizes - each switch triggers one, log_checkpoint_* parameters)

b) make dbwr faster if it is slow (async io, io slaves, multiple dbwrs)

c) add more log files to get you through the peak processing time without having

to write around.

Have a look on oracle Note:147468.1

Regards

Vinod

[Former Member]

Hi

checkpoint not complete, cannot allocate new log

this occurrs when Oracle attempts to reuse a log file but the checkpoint that

would flush the blocks that may have redo in this log file has not yet completed

-- we must wait until that checkpoint completes before we can reuse that file --

thats when this message is printed. during this time (when we cannot allocate a

new log) processing is suspended in the database while the checkpoint is made to

complete ASAP.

The major way to relieve this is to have sufficient log to carry you through

peak times. that way, we can complete the checkpoint while you are not busy.

look at alert<sid>.log file u will have a clear picture.

Or provide output of that file I can guide you how much size should be logfile for ur DB.

Regards

Vinod

[Former Member]

can we have a little more information about:

1. SAP Kernel Release

2. the security definitions of directory 'D:\oracle\BID\102\database

thank you,

Peter