Oracle DBA – A lifelong learning experience

  • Meta

  • Categories

  • Blog Stats

    • 1,654,056 hits
  • Enter your email address to subscribe to this blog and receive notifications of new posts by email.

    Join 377 other followers

  • Advertisements

informational trace files in 11g

Posted by John Hallas on June 16, 2009

Since Oracle 11G there seems to be many more informational trace files generated than ever before. Perhaps I am noticing more but I will provide three examples in support of what I am saying.

kcrroda: calling ksfdrcres to create AL or RL

Just a warning but it is due to a bug in (still not fixed in that causes diagnostic warnings to be issued after an archivelog switch. Bug 6910132 for anyone who is interested

From the same database I see trace files with the following lines in

Updating SGAs in kzam_check_limit
No rows for property:16, trail_type:12
Resetting MaxSize to default values for OS audit files
Resetting MaxSize to default values for XML audit files
No rows for property:17, trail_type:12
Resetting MaxAge to default values for OS audit files
Resetting MaxAge to default values for XML audit files
No rows for property:24, trail_type:15

I cannot find any information on this at all but I do suspect that it is another diagnostic setting that has been left enabled within the code
I will raise an SR on this matter but I don’t think it is anything for me to be worried by

From another database (again I see numerous trace files containing the line

qerfxGCol:KQFDTTIM – Error converting to LdiDateArray

Metalink note 577674.1 shows that it is yet another trace output than can be ignored
Applies to:
Oracle Server – Enterprise Edition – Version:
This problem can occur on any platform.

After upgraded to or created a new database on this version, you noticed following repetitively message at MMON process trace:

“qerfxGCol:KQFDTTIM – Error converting to LdiDateArray”

There is no further errors at alert log.

Upgraded to

This issue has been introduced in 11gR1 with the new view v$persistent_queues, where a ‘select * from v$persistent_queues;’ reproduces the error when there is a ‘null’ value for one of timestamp
columns in that view. This behavior does *not* cause any data loss; performance impact nor any effect for use of ADDM/AWR tools.

This issue has been reported on following bugs:


It has been fixed in 11.2.


One Response to “informational trace files in 11g”

  1. […] DBA – A lifelong learning experience Just another weblog « informational trace files in 11g bug 8525592 – SGA memory leak during db shutdown June 25, 2009 10 days ago I posted […]

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: