Checkpoint Not complete in alert log
Hello Gurus,
Alert log keeps displaying the following message:
Current log# 3 seq# 80148 mem# 0: /UBSUNDO/ghadb_redo03b.log
Current log# 3 seq# 80148 mem# 1: /UBSTEMP/ghadb_redo03a.log
Thu Dec 06 01:33:20 GMT 2012
Thread 1 advanced to log sequence 80149 (LGWR switch)
Current log# 1 seq# 80149 mem# 0: /UBSUNDO/ghadb_redo01b.log
Current log# 1 seq# 80149 mem# 1: /UBSTEMP/ghadb_redo01a.log
Thu Dec 06 01:34:06 GMT 2012
Thread 1 cannot allocate new log, sequence 80150
Checkpoint not complete
Current log# 1 seq# 80149 mem# 0: /UBSUNDO/ghadb_redo01b.log
Current log# 1 seq# 80149 mem# 1: /UBSTEMP/ghadb_redo01a.log
Thu Dec 06 01:34:14 GMT 2012
Thread 1 advanced to log sequence 80150 (LGWR switch)
Current log# 2 seq# 80150 mem# 0: /UBSUNDO/ghadb_redo02b.log
Current log# 2 seq# 80150 mem# 1: /UBSTEMP/ghadb_redo02a.log
Kindly advice on how to resolve this issue. Database is up for now but i donot want to bounce DB because of this archiving problem.
Thank you.
PVOWUSU wrote:
Hello Gurus,
Alert log keeps displaying the following message:
Current log# 3 seq# 80148 mem# 0: /UBSUNDO/ghadb_redo03b.log
Current log# 3 seq# 80148 mem# 1: /UBSTEMP/ghadb_redo03a.log
Thu Dec 06 01:33:20 GMT 2012
Thread 1 advanced to log sequence 80149 (LGWR switch)
Current log# 1 seq# 80149 mem# 0: /UBSUNDO/ghadb_redo01b.log
Current log# 1 seq# 80149 mem# 1: /UBSTEMP/ghadb_redo01a.log
Thu Dec 06 01:34:06 GMT 2012
Thread 1 cannot allocate new log, sequence 80150
Checkpoint not complete
Current log# 1 seq# 80149 mem# 0: /UBSUNDO/ghadb_redo01b.log
Current log# 1 seq# 80149 mem# 1: /UBSTEMP/ghadb_redo01a.log
Thu Dec 06 01:34:14 GMT 2012
Thread 1 advanced to log sequence 80150 (LGWR switch)
Current log# 2 seq# 80150 mem# 0: /UBSUNDO/ghadb_redo02b.log
Current log# 2 seq# 80150 mem# 1: /UBSTEMP/ghadb_redo02a.log
Kindly advice on how to resolve this issue. Database is up for now but i donot want to bounce DB because of this archiving problem.
Thank you.Those lines are just informational.
no error exists
Similar Messages
-
Checkpoint not complete in alert log file Oracle 11gR2 RAC
Hi,
I found checkpoint not complete in alert log file, almost every 3 seconds .
In metalink i saw for this error, archive_lag_target=0, already this value was set to 0 in my database.
We have 7 redo log groups for each instance, each group is of two redo log files, each file size is 50m.
To avoid this error what i need to do..........
please help me..................When you "checkpoint not complete" messages in your alert log this normally means your online redo logs are defined too small to handle the load and you have filled and need to switch to a new online redo log before the checkpoint triggered by the previous log switch has been completed.
Increasing your online redo log size is normally the fix for this.
HTH -- Mark D Powell --
PS - The following Oracle support document may also apply:
Checkpoint Not Complete In Alert.log Due To Setting Of Archive_lag_target [ID 435780.1]
Edited by: Mark D Powell on Nov 7, 2011 8:29 AM -
At what point oracle write "Checkpoint not complete" in alert log ?
DB version: 10.2.0.4/RHEL 5.8
During a batch run, we encountered lots of 'Checkpoint not complete' errors in alert log.
Later we discovered that ORLs were sized only 50mb and this DB had only 3 redo log group. Since this is the potential cause, we are going create at least 10 Redo log groups and increase Redo log size to 500MB.
But , I want to know what exactly causes oracle to write "Checkpoint not complete" in alert log ?
For the purpose of this discussion, I am assuming we have only 1 ORL per redo log group. Is my below assumption correct ?
ORL1
|----------------> ORL1 file got full, so, LGWR starts writing to ORL2 file. Checkpoint occurs at log switch
| DBWR writes modified blocks associated with the redo entries in ORL1 to datafiles
|
V
ORL2
|----------------> ORL2 file got full, LGWR wants to start writing to ORL3 file. Checkpoint is initiated at log switch.
| But checkpoint can't be finished due to unknowN reasons
|
V
ORL3
|---------------->Your assumption is only partly right.
I would illustrate it like
ORL1
|
|----------------> ORL1 file got full, so, LGWR starts writing to ORL2 file. Checkpoint occurs at log switch
| DBWR starts writing modified blocks associated with the redo entries in ORL1 to datafiles
|
V
ORL2
|----------------> ORL2 file got full, LGWR starts writing to ORL3 file.
| Checkpoint for ORL2 is initiated at log switch.
|
V
ORL3
|
|----------------> ORL3 file (the last member) also got full very quickly . LGWR wants to start the 'new cycle' by
writing (Reusing) to ORL1. But the checkpoint intiated by the log switch of ORL1 from the previous cycle is
not complete yet !! .
Basically you get this error when LGWR attempts to reuse an online redo log file (ORL1 in the above example) and finds that it cannot.
This is because the remaining ORL files (ORL2 and ORL3) got fully written before DB writer finished checkpointing the modified blocks associated with ORL1 yet.
Until the checkpoint of ORL1 is complete, the DB effectively hangs and user sessions have to wait until LGWR can safely reuse ORL1
Yes a larger redo log size of 10 groups can help. But make sure the I/O subsytem where ORLs are stored has no latency issues. -
"checkpoint not complete" in alert log file.
Hi, all.
I have got a message of "Checkpoint not complete" in alert log file.
Thread 2 advanced to log sequence 531
Current log# 7 seq# 531 mem# 0: \\.\REDO231
Current log# 7 seq# 531 mem# 1: \\.\REDO232
Thread 2 cannot allocate new log, sequence 532
Checkpoint not complete
Current log# 7 seq# 531 mem# 0: \\.\REDO231
Current log# 7 seq# 531 mem# 1: \\.\REDO232
I searched "Checkpoint not complete" issue in this forum.
As solutions,
1. add more redo log groups
2. increase the size of redo log
3. check I/O contention
4. set LOG_CHECKPOINT_INTERVAL, LOG_CHECKPOINT_TIMEOUT or
FAST_START_MTTR_TARGET
I think No.4 is the possible first approach in our environment.
I think No.1 and No2 are not the ploblems in our environment.
I ask the above issue oracle support center, but
I was told that "if you are not getting this message frequently, you do not need to worry about it" from an oracle engineer.
Is this true?? If I am not getting this message frequently, there is no problem
in terms of database integrity, consistency, and performance?
I will be waiting for your advice and experience in real life.
Thanks and Regards.Redo Log Tuning Advisory and Automatic Checkpoint Tuning are new features introduced in Oracle 10G, if you are on 10g you may benefit from these features.
The size of the redo log files can influence performance, because the behavior of the database writer and archiver processes depend on the redo log sizes. Generally, larger redo log files provide better performance, however it must balanced out with the expected recovery time. Undersized log files increase checkpoint activity and increase CPU usage. As rule of thumb switching logs at most once every fifteen minutes.
Checkpoint frequency is affected by several factors, including log file size and the setting of the FAST_START_MTTR_TARGET initialization parameter. If the FAST_START_MTTR_TARGET parameter is set to limit the instance recovery time, Oracle automatically tries to checkpoint as frequently as necessary. Under this condition, the size of the log files should be large enough to avoid additional checkpointing due to under sized log files.
The redo logfile sizing advisory is specified by column optimal_logfile_size of v$instance_recovery. This feature require setting the parameter "fast_start_mttr_target" for the advisory to take effect and populate the column optimal_logfile_size.
Also you can obtain redo sizing advice on the Redo Log Groups page of Oracle Enterprise Manager Database Control.
To enable automatic checkpoint tuning, unset FAST_START_MTTR_TARGET or set it to a nonzero value(This is measured in seconds and by default, this feature is not enabled, because FAST_START_MTTR_TARGET has a default value of 0). If you set this parameter to zero this feature will be disabled. When you enable fast-start checkpointing, remove or disable(set to 0) the following initialization parameters:
- LOG_CHECKPOINT_INTERVAL
- LOG_CHECKPOINT_TIMEOUT
- FAST_START_IO_TARGET
Enabling fast-start checkpointing can be done statically using the initialization files or dynamically using -
SQL> alter system set FAST_START_MTTR_TARGET=10;
Best regards. -
Checkpoint not complete error in alert log
version : 10.2.0.5 , 11.2.0.2
This is what I found about "Checkpoint not complete" from google
"+This message indicates that Oracle wants to reuse a redo log file, but the current checkpoint position is still in that log. In this case, Oracle must+
+wait until the checkpoint position passes that log. Because the incremental checkpoint target never lags the current log tail by more than 90%+
+of the smallest log file size, this situation may be encountered if DBWR writes too slowly, or if a log switch happens before the log is completely full,+
+or if log file sizes are too small.+ "
Question1.
What do they mean by Oracle reusing a redo log file ? When one ORL is full , oracle will switch to the next one ; it won't reuse it. Right ?
Question2.
"the current checkpoint position is still in that log" . What is checkpoint position ?
Question3. How often does a checkpoint occur ? (frequency as per time)Question1.
What do they mean by Oracle reusing a redo log file ? When one ORL is full , oracle will switch to the next one ; it won't reuse it. Right ?You have some groups of redo log, each redo log has members with same information. Redo log run in a circular way, when a group is full, changes to the next group of redo log and when the last group is written continue overwritten the first group.
http://docs.oracle.com/cd/B28359_01/server.111/b28310/onlineredo001.htm
Question2.
"the current checkpoint position is still in that log" . What is checkpoint position ?copy and paste from:
http://docs.oracle.com/cd/E14072_01/server.112/e10713/startup.htm#BABGDACG
"A data structure that indicates the checkpoint position, which is the SCN in the redo stream where instance recovery must begin"
Question3. How often does a checkpoint occur ? (frequency as per time)Checkpoints occur in diferents situations, not per time, please check:
http://docs.oracle.com/cd/E11882_01/server.112/e16508/startup.htm#CNCPT89045 -
Oracle 10G Checkpoint not complete Cannot allocate new log
We have an oracle 10G database that has 4 groups of 200M redo logs. We are constantly seeing Checkpoint not complete followed by Cannot allocate new log.. messages in the alert log. When I look at the v$instance_recovery table I see this:
SQL> select WRITES_MTTR, WRITES_LOGFILE_SIZE, WRITES_LOG_CHECKPOINT_SETTINGS, WRITES_OTHER_SETTINGS,
2 WRITES_AUTOTUNE, WRITES_FULL_THREAD_CKPT from v$instance_recovery;
WRITES_MTTR WRITES_LOGFILE_SIZE WRITES_LOG_CHECKPOINT_SETTINGS
WRITES_OTHER_SETTINGS WRITES_AUTOTUNE WRITES_FULL_THREAD_CKPT
0 0 66329842
0 309461 41004
It seems most of our checkpointing is being caused by the log_checkpoint_interval being set to 10000, which means we are doing 20 checkpoints during one redo log since our OS blocksize is 1024. What I'm thinking about doing is first adding two more redo log groups, and then either increasing the log_checkpoint_interval to 40000 (5 checkpoints for one redo log) or unsetting log_checkpoint_interval and setting fast_start_mttr_target to 600. Which would be the recommended parameter change? I think Oracle recommends using the fast_start_mttr_target. Are there any other suggestions?Hi
>>unsetting log_checkpoint_interval and setting fast_start_mttr_target to 600.
its a better idea,look on it
http://download-uk.oracle.com/docs/cd/B19306_01/server.102/b14237/initparams068.htm#REFRN10058
Just set fast_start_mttr_target parameter.it will resolve ur problem.
Thanks
Kuljeet -
Checkpoint not complete;;cannot allocate new log ;;; PLZ HELP ME
Hi all,
We are working on Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 on a Redhat Linux Server platform.
We are facing the following problem in the alert.log file :
Wed Aug 22 02:58:57 2007
Thread 1 cannot allocate new log, sequence 43542
Checkpoint not complete
Current log# 1 seq# 43541 mem# 0: /u01/oradata/DB01/redo01.log
Thread 1 advanced to log sequence 43542
Current log# 4 seq# 43542 mem# 0: /u01/oradata/DB01/redo04.log
Current log# 4 seq# 43542 mem# 1: /u01/oraindx/DB01/redo04.log
Wed Aug 22 03:00:00 2007
Thread 1 advanced to log sequence 43543
Current log# 5 seq# 43543 mem# 0: /u01/oradata/DB01/redo05.log
Current log# 5 seq# 43543 mem# 1: /u01/oraindx/DB01/redo05.log
Wed Aug 22 03:01:00 2007
Thread 1 cannot allocate new log, sequence 43544
Checkpoint not complete
Current log# 5 seq# 43543 mem# 0: /u01/oradata/DB01/redo05.log
Current log# 5 seq# 43543 mem# 1: /u01/oraindx/DB01/redo05.log
Thread 1 advanced to log sequence 43544
Current log# 6 seq# 43544 mem# 0: /u01/oradata/DB01/redo06.log
Current log# 6 seq# 43544 mem# 1: /u01/oraindx/DB01/redo06.log
Wed Aug 22 03:01:26 2007
Thread 1 advanced to log sequence 43545
Current log# 2 seq# 43545 mem# 0: /u01/oradata/DB01/redo02.log
Thread 1 advanced to log sequence 43546
Current log# 3 seq# 43546 mem# 0: /u01/oradata/DB01/redo03.log
Thread 1 advanced to log sequence 43547
Current log# 1 seq# 43547 mem# 0: /u01/oradata/DB01/redo01.log
Wed Aug 22 03:01:38 2007
Thread 1 cannot allocate new log, sequence 43548
Checkpoint not complete
Current log# 1 seq# 43547 mem# 0: /u01/oradata/DB01/redo01.log
I know that this message indicates that Oracle wants to reuse a redo log file, but
the current checkpoint position is still in that log. In this case, Oracle must
wait until the checkpoint position passes that log. Because the
incremental checkpoint target never lags the current log tail by more than 90%
of the smallest log file size, this situation may be encountered :
1-if DBWR writes too slowly,
or
2-if a log switch happens before the log is completely full,
or
3-if log file sizes are too small.
I read some posts in this forum regarding this error but sincerly i don't know how to find the exact cause of this error? Maybe Should I add new redo files or one new redo group? I don't know how to resolve it :( ;;;
such as I have 6 redo files 3 of them 5MB size and the others 3 files 10MB size ;
Thank you,
Regards,
Message was edited by:
HAGGARMake DBWR write more aggressively - as you are on 9i the parameter I would use is FAST_START_MTTR_TARGET=(how long you want recovery to take in seconds), the lower that number, the more aggressively DBWR has to write to keep up with the target, the advantage of this is that by the time LGWR comes to overwrite the redo log file, the chances are that DBWR has already written the "high scn#" (and beyond) from the checkpoint q.
-- This disadvantage is that you will get more I/O to your disks.
2. Create more redo log file groups - this will give DBWR more time to write before LGWR tries to overwrite a particular redolog file, again the chances are that the extra (6th) or (7th) group will give CKPT enough time to completely checkpoint beyond the "highest scn#" before that group is again required..
Which one to go for.. well that's up to you and your setup, if you have an I/O bound system then 2. would be better for you, as 1. will just increase your I/O problem, however if physical space is an issue and I/O isn't then 1. might be better (with the added advantage that instance recovery will also be faster).
Sorry for the training session, but as with everything to do with Oracle, there is rarely one solution that apply to everyone...
Gopu -
Cannot allocate new log, sequence Checkpoint not complete
Hi,
Im having very frequent log switches and Im getting error as
" cannot allocate new log, sequence Checkpoint not complete"
I was having 3 redo log groups with 50 MB each. After I found this error in the alert log; I increased teh number of redo log groups to 6 with 50MB each. Still the issue is not getting resolved.
Please suggest what will be the best solution for this.
Following is a snippet from alertlog.
==================================================
Sun Apr 19 09:14:08 2009
Thread 1 advanced to log sequence 5811
Current log# 2 seq# 5811 mem# 0: /u01/app/oracle/oradata/mview/redo02.log
Thread 1 cannot allocate new log, sequence 5812
Checkpoint not complete
Current log# 2 seq# 5811 mem# 0: /u01/app/oracle/oradata/mview/redo02.log
Sun Apr 19 09:14:18 2009
Thread 1 advanced to log sequence 5812
Current log# 3 seq# 5812 mem# 0: /u01/app/oracle/oradata/mview/redo03.log
Thread 1 cannot allocate new log, sequence 5813
Checkpoint not complete
Current log# 3 seq# 5812 mem# 0: /u01/app/oracle/oradata/mview/redo03.log
Thread 1 advanced to log sequence 5813
Current log# 1 seq# 5813 mem# 0: /u01/app/oracle/oradata/mview/redo01.log
Thread 1 cannot allocate new log, sequence 5814
Checkpoint not complete
Current log# 1 seq# 5813 mem# 0: /u01/app/oracle/oradata/mview/redo01.log
Sun Apr 19 09:14:32 2009
Thread 1 advanced to log sequence 5814
Current log# 2 seq# 5814 mem# 0: /u01/app/oracle/oradata/mview/redo02.log
Thread 1 cannot allocate new log, sequence 5815
Checkpoint not complete
Current log# 2 seq# 5814 mem# 0: /u01/app/oracle/oradata/mview/redo02.log
Thread 1 advanced to log sequence 5815
Current log# 3 seq# 5815 mem# 0: /u01/app/oracle/oradata/mview/redo03.log
Thread 1 cannot allocate new log, sequence 5816
Checkpoint not complete
Current log# 3 seq# 5815 mem# 0: /u01/app/oracle/oradata/mview/redo03.log
Sun Apr 19 09:14:44 2009
=========================================================
Regards
PratheejAnand... wrote:
Hi Sir,
Although i too had suggested increasing the redo logfile size, but after going through [http://asktom.oracle.com/pls/asktom/f?p=100:11:0::::P11_QUESTION_ID:69012348056] i was little confused as Tom has mentioned
Another way is to make the log files smaller, hence increasing the frequency with which we checkpoint ---- Can you explain why so.
I was a little surprised when I read that posting - but noticed it was dated May 2000 - when databases were still quite small and less busy. (And Tom suggested 25MB as being "modest" rather than "tiny" - which is probably what many people would call 25MB these days). And May 2000 probably means 8.0 or 8.1 - and the whole log buffer, redo generation, checkpointing technology has changed a lot since then.
Basically, if you hit "checkpoint not complete", you need more online log space so that it's possible during the busiest times to keep generating redo log information while the checkpoint queues are being cleared far enough to allow older log files to be recycled.
You can do this by adding more log files, or by increasing the sizes of the log files you use. Tom's point, I think, was that if you chose the option to add more files and kept them small (or even made them smaller) then the volume of dirty data blocks that you could create while filling a log file would be small, so the database writer wouldn't have to do much work to make each log file available for re-use. (I'm not sure I'd agree with the approach, though - even for 8i - because it could easily lead to an increase in the volume of datablocks written, even if it did bypass the checkpoint issue).
Regards
Jonathan Lewis
http://jonathanlewis.wordpress.com
http://www.jlcomp.demon.co.uk
"For every expert there is an equal and opposite expert."
Arthur C. Clarke -
Thread 1 cannot allocate new log - Checkpoint not complete caused by small
Hello, one of my customers databases (setup by the customer) is running in archivelog mode. We find every day in the archivelog more than 10x the error "...cannot allocate new log - Checkpoint not complete "
The system has theese parameters:
select group#,members,bytes from v$log;
GROUP# MEMBERS BYTES
1 2 8388608
2 2 8388608
3 2 8388608
4 2 8388608
5 2 8388608
6 2 8388608
7 2 8388608
8 2 8388608
9 2 8388608
10 2 8388608
I asked the formder admin, why the redologs has only 8mb size. The answer was: "To find out, when there was big activity in the database. The count of archivelogs are bigger if you has small redologs. If you use some 250m redologs, we cannot see when tha database has big load. But this is important in case of recovery to recover the database to the point in time before the big load was has taken place." ... ???
Okay, if the customer wants to have 8 MB redologs ... I don´t care. But how can i prevent now the error message? The only way for me is to setup more redolog groups. But it would be very confusing to have 50 or 70 groups of redologs.
What can I do else to prevent the error?what is the log frequency?
logfile size?
can you check fast_start_mttr_target as well
check the following description:
Sometimes, you can see in your alert.log file, the following corresponding
messages:
Thread 1 advanced to log sequence 248
Current log# 2 seq# 248 mem# 0: /prod1/oradata/logs/redologs02.log
Thread 1 cannot allocate new log, sequence 249
Checkpoint not complete
This message indicates that Oracle wants to reuse a redo log file, but
the current checkpoint position is still in that log. In this case, Oracle must
wait until the checkpoint position passes that log. Because the
incremental checkpoint target never lags the current log tail by more than 90%
of the smallest log file size, this situation may be encountered if DBWR writes
too slowly, or if a log switch happens before the log is completely full,
or if log file sizes are too small.
When the database waits on checkpoints,redo generation is stopped until the
log switch is done.
Edited by: CKPT on Jul 19, 2010 7:37 PM -
Thread 1 cannot allocate new log, sequence 80064 - Checkpoint not complete
Hi,
from few days we have sometimes this message into alert. I've just try to increase the size of redo log file but without success, have you got any idea?
Thank you.
Wed Jul 30 00:08:05 2014
Beginning log switch checkpoint up to RBA [0x138bd.2.10], SCN: 4473445936
Thread 1 advanced to log sequence 80061 (LGWR switch)
Current log# 1 seq# 80061 mem# 0: F:\ORACLE\PRD\ORIGLOGA\LOG_G11M1.DBF
Current log# 1 seq# 80061 mem# 1: F:\ORACLE\PRD\MIRRLOGA\LOG_G11M2.DBF
Beginning log switch checkpoint up to RBA [0x138be.2.10], SCN: 4473445939
Thread 1 advanced to log sequence 80062 (LGWR switch)
Current log# 2 seq# 80062 mem# 0: F:\ORACLE\PRD\ORIGLOGB\LOG_G12M1.DBF
Current log# 2 seq# 80062 mem# 1: F:\ORACLE\PRD\MIRRLOGB\LOG_G12M2.DBF
Beginning log switch checkpoint up to RBA [0x138bf.2.10], SCN: 4473445942
Thread 1 advanced to log sequence 80063 (LGWR switch)
Current log# 3 seq# 80063 mem# 0: F:\ORACLE\PRD\ORIGLOGA\LOG_G13M1.DBF
Current log# 3 seq# 80063 mem# 1: F:\ORACLE\PRD\MIRRLOGA\LOG_G13M2.DBF
Wed Jul 30 00:08:06 2014
Archived Log entry 80064 added for thread 1 sequence 80061 ID 0x70061a1e dest 1:
Thread 1 cannot allocate new log, sequence 80064
Checkpoint not complete
Wed Jul 30 00:08:06 2014
Archived Log entry 80065 added for thread 1 sequence 80062 ID 0x70061a1e dest 1:
Current log# 3 seq# 80063 mem# 0: F:\ORACLE\PRD\ORIGLOGA\LOG_G13M1.DBF
Current log# 3 seq# 80063 mem# 1: F:\ORACLE\PRD\MIRRLOGA\LOG_G13M2.DBF
Wed Jul 30 00:08:08 2014
Archived Log entry 80066 added for thread 1 sequence 80060 ID 0x70061a1e dest 1:
Wed Jul 30 00:08:09 2014
Completed checkpoint up to RBA [0x138bd.2.10], SCN: 4473445936
Beginning log switch checkpoint up to RBA [0x138c0.2.10], SCN: 4473445946
Thread 1 advanced to log sequence 80064 (LGWR switch)
Current log# 4 seq# 80064 mem# 0: F:\ORACLE\PRD\ORIGLOGB\LOG_G14M1.DBF
Completed checkpoint up to RBA [0x138c0.2.10], SCN: 4473445946
Current log# 4 seq# 80064 mem# 1: F:\ORACLE\PRD\MIRRLOGB\LOG_G14M2.DBF
Archived Log entry 80067 added for thread 1 sequence 80063 ID 0x70061a1e dest 1:
Completed checkpoint up to RBA [0x138bf.2.10], SCN: 4473445942
Completed checkpoint up to RBA [0x138be.2.10], SCN: 4473445939========================================================
GENERIC OPATCH VERSION - FOR USE IN SAP ENVIRONMENT ONLY
========================================================
Oracle Installer di patch provvisorie versione 11.2.0.3.1
Copyright (c) 2012, Oracle Corporation. Tutti i diritti riservati.
Oracle Home : I:\oracle\PRD\11203
Central Inventory : C:\Program Files\Oracle\Inventory
from : n/a
OPatch version : 11.2.0.3.1
OUI version : 11.2.0.3.0
Log file location : I:\oracle\PRD\11203\cfgtoollogs\opatch\opatch2014-07-30_00-4
7-57AM_1.log
Lsinventory Output file location : I:\oracle\PRD\11203\cfgtoollogs\opatch\lsinv\
lsinventory2014-07-30_00-47-57AM.txt
Prodotti di livello superiore installati (1):
Oracle Database 11g 11.2.0.3.0
Ci sono 1 prodotti installati in questa Oracle home.
Patch provvisorie (6) :
Patch 16167942 : applied on Sat May 18 11:50:42 CEST 2013
Unique Patch ID: 15646955
Patch description: "ORACLE 11G 11.2.0.3 PATCH 15 BUG FOR WINDOWS (64-BIT AMD64
AND INTEL EM64)"
Created on 01 Feb 2013, 00:06:51 hrs PST8PDT
Bugs fixed:
16167942, 15841373, 14252187, 13877007, 14249514, 13891981, 12637294
14511876, 14309075, 13736413, 12862170, 13901201, 12819999, 16019955
15996520, 14775679, 13902963, 15924589, 14525739, 14744263, 12838063
15910002, 14751895, 14107475, 13262857, 14641969, 15938047, 15982436
13924173, 14761411, 16042648, 13337530, 14810890, 13605675, 7335665
12686027, 16011871, 13729351, 13923995, 12813641, 12985237, 14600776
14565062, 13066936, 14510516, 14192781, 14164191, 14505752, 15834269
13559463, 14702500, 12345305, 14467027, 14807785, 14590564, 13849733
13916549, 14755945, 15869211, 13365021, 13972394, 14193629, 14808639
14189694, 13848402, 14226599, 13621258, 13827380, 14762511, 14064573
13777449, 15848120, 14546673, 14546638, 14546575, 14469008, 14263073
14263036, 14258925, 14205448, 14023636, 14035825, 13685544, 14040433
13593999, 13026410, 12964067, 12873183, 12857027, 12345082, 14589750
14668670, 13791678, 13769577, 13658087, 14230270, 13890080, 13810393
13551402, 14644185, 13686047, 12583611, 14488943, 14176879, 13727644
13517951, 13361350, 14373728, 13602883, 13580513, 10219624, 14645769
14007968, 14827344, 9153183, 15853081, 14138130, 14168099, 14810093
13845120, 14277586, 14271305, 13879428, 13938166, 12558569, 10260842
14569263, 14100232, 13912373, 13653178, 14242977, 14102704, 14001941
13993634, 13634583, 14828076, 13645875, 14398795, 13879553, 12940620
14663556, 12327035, 14207902, 12557401, 14653598, 14587310, 14224606
14577426, 14386985, 13783957, 12656350, 11836374, 14485163, 14624988
14582487, 14332938, 14166276, 14479390, 14372670, 14038163, 13535104
13744724, 14245087, 14305767, 14731193, 14313519, 14500723, 12928700
12571916, 14245825, 13642044, 9706792, 13693929, 13903046, 14581922
14142884, 14393900, 9778542, 13115786, 13427062, 14164849, 13399711
11686700, 14175146, 14499293, 13615767, 14625969, 14513934, 14320472
14613223, 13040943, 12812148, 14360965, 13911821, 14140535, 14204172
13949042, 14367567, 9949330, 14467202, 14323857, 13834065, 13632653
14110275, 13549808, 14196818, 13819727, 9751365, 10029609, 11846912
12646510, 12766337, 12826115, 12860701, 12865360, 12973529, 13031176
13040909, 13061085, 13066239, 13071375, 13111783, 13114306, 13345188
13376866, 13393115, 13406688, 13408107, 13433178, 13459147, 13531801
13553502, 13603792, 13608532, 13622539, 13622968, 13738130, 13961338
14054189, 13851432, 14063422, 13973307, 14119388, 14282903, 14517263
13716797, 14465787, 14613900, 14304758, 14251904, 14214257, 14153867
14009845, 13889047, 13888719, 13820621, 13697828, 12663376, 11675721
12889329, 13410987, 13965075, 13869978, 13843080, 13825231, 13582411
13550689, 13023609, 13000491, 10418841, 10317921, 13523527, 13498267
14096743, 14010695, 13947200, 14259185, 14280458, 14276345, 14543814
13804294, 13718279, 13612575, 13430938, 13384182, 13377816, 13250244
12794305, 12693626, 12352406, 12879628, 13534412, 13524698, 13743987
14207317, 13918644, 14198511, 14088346, 12791981, 13011409, 13038684
12865902, 12768840, 14076523, 13632809, 14458246, 13359289, 12794025
9952132, 13780816, 12950694, 14162791, 13093358, 14255600, 13936424
14301592, 14050233, 13528725, 14500052, 10146616, 14409183, 14324057
14313389, 5918695, 12430142, 13399435, 13913630, 13732226, 10084752
13591624, 14237793, 14013094, 10229475, 13078786, 14052474, 13637058
12646746, 13000553, 14254795, 14215010, 13922729, 13942694, 12898637
14309390, 13958038, 10214323, 13710236, 14115858, 14240544, 14158332
13073613, 11074304, 13868705, 12723295, 13853654, 14074606, 13784384
14386810, 14223718, 14018752, 13258936, 13723052, 12898020, 10625145
14052871, 13076238, 13992002, 13242070, 12955701, 12693573, 14026888
13984965, 13366199, 13843286, 13616375, 12839247, 8547978, 13714926
13023854, 13910420, 11837095, 12842909, 12959852, 13632140, 13780035
13860201, 13711083, 13628002, 13397104, 12358083, 13743357, 13945708
10384051, 13591484, 13051250, 13727853, 12959627, 14095820, 5144934
13657605, 13582702, 12966665, 13463131, 13773133, 12918738, 13099577
13690409, 13645917, 11708510, 14042380, 13627489, 13652437, 12733042
13907462, 13608299, 13624984, 9095696, 12794090, 9706532, 13469158
13947480, 13555112, 13399236, 12910565, 13790109, 12552578, 13896848
13737746, 13080778, 13458016, 13873885, 12312133, 12731940, 12672969
13355095, 13981051, 13467683, 13457582, 13370330, 13340388, 12976376
12797420, 12658411, 10133521, 9761357, 13827394, 13729832, 13851978
13559770, 13592937, 13592919, 13478856, 13559540, 13641696, 13729808
13632530, 14100237, 11071989, 13786142, 13839641, 13041324, 13857364
13853089, 13806545, 13726162, 13657366, 13617861, 13604057, 13483672
12959140, 12914722, 12910033, 12771830, 13776758, 13339443, 12680491
10114953, 12966774, 13965211, 12424121, 13478060, 13786778, 13579992
13705338, 13603613, 13476583, 12745662, 9190186, 13530646, 13520452
9019231, 13610777, 12905053, 10263668, 13550185, 13385346, 13448206
12772404, 13911711, 11072246, 13104881, 13863326, 12889054, 13775960
13777823, 13464002, 11824898, 13535622, 13916709, 12880299, 12918338
12529945, 13811209, 14058362, 13724808, 13885389, 13649031, 13350245
13553883, 13388104, 13635347, 13404129, 13031118, 12530140, 13023541
13767921, 13787482, 13641076, 13807411, 13724992, 12965899, 13791443
12879027, 13584130, 13495307, 12594032, 13709220, 13247965, 13243072
13683125, 13652493, 12957127, 10215977, 13014128, 13040331, 12857222
12977501, 12664456, 12405931, 13525554, 13492863, 13573521, 13873471
13366268, 13352423, 13460353, 12709476, 13652088, 13886023, 13942723
12919564, 12894807, 12829021, 12612118, 11063191, 13503598, 13482688
13354082, 13484963, 13395403, 13542159, 12983611, 13718476, 12846562
9659614, 13326736, 11846902, 11665727, 13257247, 13588248, 13544396
13566938, 13615517, 13425727, 13037709, 12730342, 12349553, 13502441
13258062, 13251796, 13247273, 12659561, 12639013, 12594616, 11772838
13570057, 12403721, 12585543, 12784549, 12834800, 12975771, 13040171
13058950, 13063120, 13077335, 13365700, 13382280, 13384397, 13440516
13454210, 13457537, 13477790, 13496250, 13501787, 13505390, 13506110
13524899, 13572659, 13594712, 13617627, 13326289, 13555974, 13035360
13420224, 13419660, 13036331, 13332439, 13420174, 12583826, 13358781
11883969, 13524237, 12867713, 13328193, 13516727, 11865420, 13502183
13259364, 13371153, 12998795, 13413168, 12897902, 13044108, 12971242
12834027, 12620823, 13420516, 12849377, 12975811, 12646784, 12829429
12538907, 12950823, 12848480, 12823838, 13366202, 13002015, 12834777
13001901, 13017428, 13082238, 12965049, 11840910, 12656535, 12617123
13073340, 12925041, 12938841, 13023632, 13066371, 12942119, 11877623
12810890, 12995950, 12765467, 12934171, 13070939, 12535346, 12985184
13103913, 12765868, 12622441, 12876314, 12820045, 13038806, 13090686
12923168, 13362079, 12591252, 12718090, 12873909, 10350832, 12795861
13039908, 12976590, 13017584, 12627504, 13263435, 12847466, 12797765
12758736, 12878750, 12861463, 13024624, 12764337, 12662040, 13068077
12914824, 13074261, 12668341, 12597906, 12932852, 13045518, 12897651
12960925, 12728585, 13019958, 12902661, 12886827, 12913474, 3522216
12678920, 12885323, 13334158, 12947871, 12896850, 13001955, 12784559
12827166, 9703627, 12772345, 12905058, 13345868, 10357727, 12827493
13004894, 12780983, 12842804, 13146719, 12655301, 12960302, 13085732
12979199, 12638117, 13357509, 12401111, 12857064, 8631856, 13035804
13355963, 12845115, 12695029, 12990582, 12971775, 12867511, 12917230
12582664, 12849688, 12950644, 12588744, 13011520, 12899169, 12823042
Patch 14658090 : applied on Sat May 18 11:40:34 CEST 2013
Unique Patch ID: 15859799.1
Created on 27 Jan 2013, 08:31:45 hrs PST8PDT
Bugs fixed:
14658090
Patch 13575265 : applied on Sat May 18 11:40:14 CEST 2013
Unique Patch ID: 14606745
Created on 27 Feb 2012, 02:10:47 hrs PST8PDT
Bugs fixed:
13575265
Patch 13508485 : applied on Sat May 18 11:39:34 CEST 2013
Unique Patch ID: 14395138
Created on 21 Dec 2011, 13:23:38 hrs PST8PDT
Bugs fixed:
13508485
Patch 12325243 : applied on Sat May 18 11:38:51 CEST 2013
Unique Patch ID: 14243031
Created on 7 Nov 2011, 11:57:40 hrs PST8PDT
Bugs fixed:
12325243
Patch 9584028 : applied on Sat May 18 11:38:31 CEST 2013
Created on 22 Jun 2012, 11:39:40 hrs CEST
Bugs fixed:
9584028
OPatch succeeded. -
Thread 1 cannot allocate new log, sequence 5720 Checkpoint not completed
Hi,
I can see a lot of messages like that:
Thread 1 cannot allocate new log, sequence 5720
Checkpoint not complete
What is the problem?? I think is about permissions.
What permissions do i need to give to log_archive_dest directory and redo log file directory??
Is the only thing that i can see that coulb be the problem because my HP-UX change the permissions of some directories sometimes and the SYS ADMIN don´t know how and why.
I can do:
SQL> alter system switch logfile;
System altered.
SQL> alter system checkpoint;
System altered.
Tks,
Paulo.Thread 1 cannot allocate new log, sequence 5720
Checkpoint not complete
What is the problem?Lgwr wants to switch to and reuse the "tail" redo group, but since checkpointing for that group is not yet completed, lgwr has to wait until all data, that the redo protects, has been written down to datafiles. This stops (temporarily) writing of redo from buffer to log files and you get that message in the alert.log.
How many redo log groups and what is their size? -
Thread 1 cannot allocate new log, sequence 1196,Checkpoint not complete
We were receiving the following messages in alert log. We have Oracle 10g R2 database having four redo log groups with two members each (50 MB). To overcome this error yesterday we added two more groups with same config. Again we received the same message in the alert log.
Alert Log contents:
Fri Dec 22 11:21:39 2006
Thread 1 cannot allocate new log, sequence 1193
Checkpoint not complete
Current log# 1 seq# 1192 mem# 0: /u02A/oradata/admin/origlogA/redo01.log
Thread 1 advanced to log sequence 1193
Current log# 5 seq# 1193 mem# 0: /u02A/oradata/admin/origlogA/redo05.log
Thread 1 cannot allocate new log, sequence 1194
Checkpoint not complete
Current log# 5 seq# 1193 mem# 0: /u02A/oradata/admin/origlogA/redo05.log
Current log# 5 seq# 1193 mem# 1: /u02B/oradaFri Dec 22 11:21:50 2006
Thread 1 advanced to log sequence 1194
Current log# 6 seq# 1194 mem# 0: /u02A/oradata/admin/origlogA/redo06.log
Current log# 6 seq# 1194 mem# 1: /u02B/oradata/admin/origlogB/redo06_2.log
Thread 1 advanced to log sequence 1195
Current log# 2 seq# 1195 mem# 0: /u02A/oradata/admin/origlogA/redo02.log
Current log# 2 seq# 1195 mem# 1: /u02B/oradata/admin/origlogB/redo02_2.log
Fri Dec 22 11:22:05 2006
Thread 1 cannot allocate new log, sequence 1196
Checkpoint not complete
Current log# 2 seq# 1195 mem# 0: /u02A/oradata/admin/origlogA/redo02.log
Current log# 2 seq# 1195 mem# 1: /u02B/oradata/admin/origlogB/redo02_2.log
Thread 1 advanced to log sequence 1196
Current log# 3 seq# 1196 mem# 0: /u02A/oradata/admin/origlogA/redo03.log
Current log# 3 seq# 1196 mem# 1: /u02B/oradata/admin/origlogB/redo03_2.log
Thread 1 cannot allocate new log, sequence 1197
Checkpoint not completeYou might not want to revivify threads from 2006. Create a new thread, including all the information to make it a [url http://catb.org/esr/faqs/smart-questions.html]smart question. Which version and patch level of Oracle are you on, which platform, how often are your logs switching, a relevant clip from your alert log surrounded by {noformat}{noformat} tags, etc.
-
Thread 1 cannot allocate new log, sequence 714 - Checkpoint not complete
I'm working in a Oracle 10g database, running on RHEL. The alert_*.log file is putting out this type of text for the past few months:
Thread 1 advanced to log sequence 713 (LGWR Switch)
Current log#2 seq# 713 mem# 0: /dbfiles/..../onlinelog/filename.log
Current log #2 ..........
Thread 1 cannot allocate new log, sequence 714
Checkpoint not complete
Any ideas to get me pointed in the right direction is appreciated,
Thank you in advance,
WesThe immediate fixes Vishal suggests are the standard answer, but there is more to it, as the MOS doc he references shows. Additional questions I would ask:
How long is the delay between the inability to switch and when it actually switches? How many datafiles do you have? What is waiting in the db?
In general, I find making log files sized for the rare massive updates, then using the built-in timeouts to switch every 20 or 30 minutes (depending on management recoverability expectations), helps avoid some of these problems. More specifically, run a statspack or awr (if licensed) report for maybe an hour during heavy times, and see what it thinks the waits are. Tuning is an iterative process, and sometimes different things can cause similar symptoms. Sometimes fixing the biggest problem (which is often poor SQL) can radically change the symptoms observed. Other times you find you have dying hardware, or someone messed up a switch configuration. -
Thread 1 cannot allocate new log, sequence 1558 Checkpoint not complete
hi,
i m working on oracle 10g rac database on aix machine . i m getting this error on peck time
Thread 1 cannot allocate new log, sequence 1558 Checkpoint not complete
i read lots of documents and they asked to increase size of redo file or add more redo files.
can u plz describe me y m i getting this error ? & how adding redo file can help in this error.
thxswhen yours current redo log filled and then started to switch another log then checkpoint occurs ,this checkpoint started to write dirty buffer from buffer cache to datafile , you cannot reuse this logfile unless checkpoint process writes alls dirty buffer from buffer cache to disk which contained this redo log file.If you attempt to reuse the same log file which cause to checkpoint upon log switch then you will get this error.
Typically this error comes where yours number of redo log switches occuring too frequently or you have less number of redo logs.
lets say if you have 2 redolog file A and B,yours A redolog filled and then oracle switch from redo log A to B,checkpoint occurs,DBWRn started to write dirty buffer to disk meanwhile yours redo log B also get filled antoher log switch occurs to be attempt to reuse redo log file A ,but redo log A will not be entertain unless the previous checpoint completed to write alls dirty block from buffer cache to hard disk which is contained thats redo log A.
Adding redo log will be helpful in this case that redo log will switch to another new added redo log say C and A log file will get more time to be completed checkpoint which he/she contains contents.
Khurram -
Log file switch (checkpoint not complete)
HI,
I am using Oracle 9.2 on rhel
IN the statspack report I am getting one of the event I.e log file switch (checkpoint not complete).Statspack duration is about 1.5 hrs...any suggestion
Instance Efficiency Percentages (Target 100%)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Buffer Nowait %: 99.97 Redo NoWait %: 98.31
Buffer Hit %: 95.84 In-memory Sort %: 100.00
Library Hit %: 99.57 Soft Parse %: 98.51
Execute to Parse %: 72.70 Latch Hit %: 99.71
Parse CPU to Parse Elapsd %: 53.15 % Non-Parse CPU: 99.10
Shared Pool Statistics Begin End
Memory Usage %: 93.66 93.74
% SQL with executions>1: 60.41 60.94
% Memory for SQL w/exec>1: 60.89 61.66
Top 5 Timed Events
~~~~~~~~~~~~~~~~~~ % Total
Event Waits Time (s) Ela Time
log file switch (checkpoint incomplete) 35,936 35,100 42.81
enqueue 6,144 16,684 20.35
buffer busy waits 17,190 13,346 16.28
wait for a undo record 51,967 4,931 6.01
ARCH wait on SENDREQ 877 4,813 5.87
-------------------------------------------------------------Please find the whole stats[pack report
{code}
STATSPACK report for
DB Name DB Id Instance Inst Num Release Cluster Host
ICAI 1504443695 icai 1 9.2.0.8.0 NO icaidb.icai.
org
Snap Id Snap Time Sessions Curs/Sess Comment
Begin Snap: 70 04-Aug-10 14:27:14 162 34.7
End Snap: 73 04-Aug-10 15:30:43 254 55.4
Elapsed: 63.48 (mins)
Cache Sizes (end)
~~~~~~~~~~~~~~~~~
Buffer Cache: 4,928M Std Block Size: 8K
Shared Pool Size: 1,312M Log Buffer: 1,024K
Load Profile
~~~~~~~~~~~~ Per Second Per Transaction
Redo size: 96,260.76 53,769.94
Logical reads: 13,998.20 7,819.20
Block changes: 1,227.83 685.85
Physical reads: 592.13 330.76
Physical writes: 19.93 11.13
User calls: 313.12 174.91
Parses: 31.41 17.55
Hard parses: 0.47 0.26
Sorts: 11.61 6.49
Logons: 0.11 0.06
Executes: 115.04 64.26
Transactions: 1.79
% Blocks changed per Read: 8.77 Recursive Call %: 26.28
Rollback per transaction %: 5.43 Rows per Sort: 472.17
Instance Efficiency Percentages (Target 100%)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Buffer Nowait %: 99.97 Redo NoWait %: 98.31
Buffer Hit %: 95.84 In-memory Sort %: 100.00
Library Hit %: 99.57 Soft Parse %: 98.51
Execute to Parse %: 72.70 Latch Hit %: 99.71
Parse CPU to Parse Elapsd %: 53.15 % Non-Parse CPU: 99.10
Shared Pool Statistics Begin End
Memory Usage %: 93.66 93.74
% SQL with executions>1: 60.41 60.94
% Memory for SQL w/exec>1: 60.89 61.66
Top 5 Timed Events
~~~~~~~~~~~~~~~~~~ % Total
Event Waits Time (s) Ela Time
log file switch (checkpoint incomplete) 35,936 35,100 42.81
enqueue 6,144 16,684 20.35
buffer busy waits 17,190 13,346 16.28
wait for a undo record 51,967 4,931 6.01
ARCH wait on SENDREQ 877 4,813 5.87
Wait Events for DB: ICAI Instance: icai Snaps: 70 -73
-> s - second
-> cs - centisecond - 100th of a second
-> ms - millisecond - 1000th of a second
-> us - microsecond - 1000000th of a second
-> ordered by wait time desc, waits desc (idle events last)
Avg
Total Wait wait Waits
Event Waits Timeouts Time (s) (ms) /txn
log file switch (checkpoint 35,936 35,886 35,100 977 5.3
enqueue 6,144 5,660 16,684 2716 0.9
buffer busy waits 17,190 5,325 13,346 776 2.5
wait for a undo record 51,967 49,137 4,931 95 7.6
ARCH wait on SENDREQ 877 0 4,813 5489 0.1
log file switch (archiving n 3,705 3,653 3,600 972 0.5
db file sequential read 600,718 0 621 1 88.1
log file sync 6,826 140 561 82 1.0
log file parallel write 7,052 0 421 60 1.0
log buffer space 1,361 16 230 169 0.2
db file scattered read 289,115 0 212 1 42.4
switch logfile command 116 23 160 1377 0.0
wait for stopper event to be 1,924 1,111 123 64 0.3
control file parallel write 1,355 0 63 46 0.2
PX Deq: Txn Recovery Start 1,253 0 36 29 0.2
SQL*Net break/reset to clien 560 0 20 36 0.1
local write wait 18 15 17 918 0.0
log file switch completion 21 7 9 442 0.0
control file sequential read 237,021 0 6 0 34.8
log file sequential read 437 0 6 13 0.1
BFILE get length 297 0 2 7 0.0
latch free 485 67 2 4 0.1
BFILE read 1,023 0 1 1 0.2
log file single write 18 0 0 16 0.0
SQL*Net more data to client 13,785 0 0 0 2.0
process startup 10 0 0 9 0.0
control file single write 10 0 0 4 0.0
row cache lock 34 0 0 0 0.0
db file single write 1 0 0 14 0.0
LGWR wait for redo copy 89 0 0 0 0.0
PX Deq: Signal ACK 3 0 0 4 0.0
PX Deq: Join ACK 5 0 0 1 0.0
BFILE open 106 0 0 0 0.0
db file parallel read 25 0 0 0 0.0
async disk IO 1,383 0 0 0 0.2
db file parallel write 255 0 0 0 0.0
BFILE internal seek 1,023 0 0 0 0.2
direct path read 843 0 0 0 0.1
BFILE closure 106 0 0 0 0.0
undo segment extension 844 844 0 0 0.1
direct path write 96 0 0 0 0.0
SQL*Net message from client 1,188,764 0 445,926 375 174.3
virtual circuit status 125 125 3,660 29277 0.0
wakeup time manager 86 86 2,451 28506 0.0
PX Idle Wait 755 750 1,466 1941 0.1
jobq slave wait 60 60 176 2930 0.0
SQL*Net more data from clien 3,035 0 1 0 0.4
SQL*Net message to client 1,188,882 0 1 0 174.3
Wait Events for DB: ICAI Instance: icai Snaps: 70 -73
-> s - second
-> cs - centisecond - 100th of a second
-> ms - millisecond - 1000th of a second
-> us - microsecond - 1000000th of a second
-> ordered by wait time desc, waits desc (idle events last)
Avg
Total Wait wait Waits
Event Waits Timeouts Time (s) (ms) /txn
Background Wait Events for DB: ICAI Instance: icai Snaps: 70 -73
-> ordered by wait time desc, waits desc (idle events last)
Avg
Total Wait wait Waits
Event Waits Timeouts Time (s) (ms) /txn
ARCH wait on SENDREQ 877 0 4,813 5489 0.1
buffer busy waits 2,164 1,176 1,184 547 0.3
log file parallel write 7,052 0 421 60 1.0
wait for stopper event to be 1,924 1,111 123 64 0.3
control file parallel write 1,301 0 57 44 0.2
enqueue 393 0 10 26 0.1
control file sequential read 234,452 0 6 0 34.4
log file sequential read 431 0 6 13 0.1
db file scattered read 124 0 1 10 0.0
log buffer space 40 0 1 13 0.0
log file single write 15 0 0 20 0.0
db file sequential read 20 0 0 9 0.0
process startup 7 0 0 8 0.0
latch free 19 3 0 2 0.0
LGWR wait for redo copy 89 0 0 0 0.0
PX Deq: Signal ACK 3 0 0 4 0.0
PX Deq: Join ACK 5 0 0 1 0.0
db file parallel write 255 0 0 0 0.0
async disk IO 793 0 0 0 0.1
rdbms ipc reply 1 0 0 0 0.0
direct path read 88 0 0 0 0.0
direct path write 88 0 0 0 0.0
rdbms ipc message 50,357 3,296 16,467 327 7.4
pmon timer 1,271 1,251 3,653 2874 0.2
smon timer 64 0 2,302 35963 0.0
SQL ordered by Gets for DB: ICAI Instance: icai Snaps: 70 -73
-> End Buffer Gets Threshold: 10000
-> Note that resources reported for PL/SQL includes the resources used by
all SQL statements called within the PL/SQL code. As individual SQL
statements are also reported, it is possible and valid for the summed
total % to exceed 100
CPU Elapsd
Buffer Gets Executions Gets per Exec %Total Time (s) Time (s) Hash Value
5,652,833 456 12,396.6 10.6 20.04 1062.67 285625578
SELECT /*+ INDEX(OT_DAK_ENTRY_DETL IDM_DED_NAME) */DEH_TXN_CODE
,DEH_NO FROM OT_DAK_ENTRY_HEAD,OT_DAK_ENTRY_DETL WHERE DEH_SY
S_ID = DED_DEH_SYS_ID AND TRUNC(DEH_APPLICATION_DT) = :b1 AND
DED_DAK_CODE = :b2 AND DED_NAME LIKE LTRIM(RTRIM(:b3)) || '%'
AND NVL(DED_INSTR_NO,'XXXXXX') = NVL(:b4,'XXXXXX') AND TRUNC(
5,096,348 189 26,964.8 9.6 23.64 23.25 1772835295
select decode(level,1,'',2,' ',3,' ',4,' ',5,'
', ' ') || decode(:1,'ENG',menu_option_desc,menu_opt
ion_desc_bl) "OPTION", menu_parent_id "PARENT", menu_action_type
"TYPE",menu_action "ACTION", decode(level,1,'',2,' ',3,' ',4,'
',5,' ', ' ') ||decode(menu_action_type, 'M', '+', 'o'
4,894,185 96 50,981.1 9.2 7.89 10.11 23088203
INSERT INTO OT_MEM_FEE_COL_DETL(MFCD_FEE_TYPE,MFCD_CONDON_FEE_YN
,MFCD_EXCESS_USED_YN,MFCD_CONDN_CODE,MFCD_PM_CODE,MFCD_CURR_CODE
,MFCD_INSTR_NO,MFCD_INSTR_DT,MFCD_AMT,MFCD_BANK_CODE,MFCD_INSTR_
TYPE,MFCD_BRANCH,MFCD_COLLECTION,MFCD_FM_DT,MFCD_TO_DT,MFCD_RES_
CODE,MFCD_CR_UID,MFCD_CR_DT,MFCD_UPD_UID,MFCD_UPD_DT,MFCD_CONDON
4,885,684 152 32,142.7 9.2 7.64 8.87 1007886847
SELECT MIN(MFCH_NO) FROM OT_MEM_FEE_COL_HEAD, OT_MEM_FEE_COL_DET
L WHERE MFCH_SYS_ID = MFCD_MFCH_SYS_ID AND MFCH_REF_NO = :B4 AND
MFCH_REF_TXN_CODE = :B3 AND MFCD_INSTR_NO = :B2 AND MFCD_BANK_C
ODE = :B1 AND MFCD_AMT > 0
2,680,356 446 6,009.8 5.0 95.57 125.49 197211170
SELECT /*+ INDEX(OT_STUDENT_FEE_COL_IPCC_HEAD OT_STUDENT_FEE_COL
IPCCHEAD_UK01) */SFCH_SYS_ID,SFCH_DT,DECODE(NVL(SSTN_SRN,SFCH
TEMPREF_NO),SSTN_SRN, NULL ,SFCH_TEMP_REF_NO) SFCH_TEMP_REF_NO
,NVL(SFCH_STUD_SRN,SSTN_SRN) SFCH_STUD_SRN,SFCH_COURSE_CODE,SFCH
SCHEMECODE,SFCH_EXMP_STUD_YN,SFCH_EXMP_STUD_REASON,DEH_APPLICA
2,288,204 1 2,288,204.0 4.3 54.31 59.36 3103356680
DECLARE job BINARY_INTEGER := :job; next_date DATE := :mydate;
broken BOOLEAN := FALSE; BEGIN BEGIN /*Quest SOO PPCM job */ qu
est_ppcm_snapshot_pkg.take_snapshot; END; :mydate := next_date;
IF broken THEN :b := 1; ELSE :b := 0; END IF; END;
2,253,877 1 2,253,877.0 4.2 52.70 56.21 579012758
DELETE FROM QUEST_PPCM_SQL_TEXT TXT WHERE INSTANCE_ID >= 0 AND N
OT EXISTS (SELECT 1 FROM QUEST_PPCM_SQL_SNAPSHOT SNAP WHERE SNAP
.SNAPSHOT_ID > 0 AND SNAP.INSTANCE_ID= TXT.INSTANCE_ID AND SNAP.
SQL_ID = TXT.SQL_ID)
1,656,006 24 69,000.3 3.1 10.00 24.26 4081782417
SELECT PISH_COURSE_CODE FROM OV_STU_PAYINSLIP_IPCC_DTL WHERE
PISH_BANK_CODE = :b1 AND PISH_NO BETWEEN :b2 AND :b3 AND PISD_
CURR_CODE = :b4 AND PISH_REGION_CODE = :b5 ORDER BY 1
SQL ordered by Gets for DB: ICAI Instance: icai Snaps: 70 -73
-> End Buffer Gets Threshold: 10000
-> Note that resources reported for PL/SQL includes the resources used by
all SQL statements called within the PL/SQL code. As individual SQL
statements are also reported, it is possible and valid for the summed
total % to exceed 100
CPU Elapsd
Buffer Gets Executions Gets per Exec %Total Time (s) Time (s) Hash Value
1,567,946 12 130,662.2 2.9 21.99 47.39 1585476974
SELECT NVL(TO_CHAR(A.DEH_APPLICATION_DT,'DD/MM/RRRR'), NULL ),NV
L(TO_CHAR(A.DEH_DT,'DD/MM/RRRR'), NULL ) FROM OT_DAK_ENTRY_HEA
D A,OT_DAK_ENTRY_DETL B,OT_FIRM_NAME_APPR_HEAD C WHERE A.DEH_SY
S_ID = B.DED_DEH_SYS_ID AND B.DED_DAK_SYS_ID = C.FNAH_DED_SYS_I
D AND C.FNAH_SYS_ID = (SELECT MAX(B.FNAH_SYS_ID) FROM OT_FIR
1,216,226 4 304,056.5 2.3 9.90 54.25 937031003
SELECT TRIM(STUD_SRN)
Q1_REGNO, TR
IM(STUD_TEMP_REF_NO)
Q1_TEMPNO, STUD_TITLE
1,138,801 178 6,397.8 2.1 18.13 1009.80 1617597
SELECT SRN,ACTIVITYDESCRIPTION,STATUS,DOCUMENTNO,DOCUMENTDATE FR
OM OV_ART_TRANS_STATUS WHERE (SRN=:1) order by DOCUMENTDATE
1,029,221 230 4,474.9 1.9 20.27 20.76 1838125769
SELECT MRH_DT,MRH_FIRST_NAME,MRH_MIDDLE_NAME,MRH_SUR_NAME,MRH_ST
ATUS FROM OM_MEM_REG_HEAD WHERE DECODE(:b1,1,MRH_MRN,MRH_MFCH
TEMPREF_NO) = :b2
778,949 52 14,979.8 1.5 20.32 21.85 4142254844
SELECT LTRIM(RTRIM(DECODE(TIT_NAME,'MR.','CA.','MS.','CA.','MRS.
','CA.') || ' ' || MRH_FIRST_NAME || ' ' || MRH_MIDDLE_NAME
|| ' ' || MRH_SUR_NAME || ' ' || DECODE(MRH_APPR_UID, NULL ,
NULL ,DECODE(MRH_MEM_STATUS,2, NULL ,DECODE(MRH_FELLOW_STATUS_YN
,'Y','FCA','ACA'))) || DECODE(MRH_RESI_STATUS,'A','
755,893 517 1,462.1 1.4 90.43 89.07 1033584013
SELECT DECODE(MFCD_FEE_TYPE,'M08',1,'M05',2,'M06',3,'M09',4,'M10
',5,'M11',6,'M12',7,'M07',8,'M13',9,'M14',10,'M15',11,'M04',12,'
M03',13,'M02',14,'M01',15,'M21',16,'M22',17,'M23',18,'EXCESS',19
,20) FEE_SEQ,MFCD_FEE_TYPE FEE_TYPE,SUM(MFCD_AMT) AMOUNT FROM
OT_MEM_FEE_COL_HEAD,OT_MEM_FEE_COL_DETL WHERE MFCH_SYS_ID = MFC
751,010 1,090 689.0 1.4 28.61 31.41 1734754400
SELECT ROWID,PIIPD_ICAI_EXAM_APPEARED,PIIPD_REG_NO,PIIPD_MTH,PII
PD_YR,PIIPD_ROLL_NO,PIIPD_EXT_EXAM_APPEARED,PIIPD_EXAM_CODE_1,PI
IPD_SUBJ_CODE_1,PIIPD_GROUP_1,PIIPD_ROLL_NO_1,PIIPD_LAST_PAPER_D
T_1,PIIPD_EXAM_CODE_2,PIIPD_SUBJ_CODE_2,PIIPD_GROUP_2,PIIPD_ROLL
SQL ordered by Reads for DB: ICAI Instance: icai Snaps: 70 -73
-> End Disk Reads Threshold: 1000
CPU Elapsd
Physical Reads Executions Reads per Exec %Total Time (s) Time (s) Hash Value
227,513 2 113,756.5 10.1 22.04 79.36 2837394537
SELECT STUD_SRN,STUD_FIRST_NAME,STUD_MIDDLE_NAME,STUD_MAIDEN_NAM
E,STUD_SURNAME,STUD_FATHER_NAME,STUD_BIRTH_DT,STUD_COMM_CODE,STU
D_SEX,STUD_HANDICAPPED_YN,STUD_HANDICAPPED_REASON,STUD_LANG_CODE
,STUD_NATIONALITY_CODE,STUD_EMAIL,STUD_PERMNT_ADDR_LINE_1,STUD_P
ERMNT_ADDR_LINE_2,STUD_PERMNT_ADDR_LINE_3,STUD_PERMNT_ADDR_LINE_
220,939 12 18,411.6 9.8 21.99 47.39 1585476974
SELECT NVL(TO_CHAR(A.DEH_APPLICATION_DT,'DD/MM/RRRR'), NULL ),NV
L(TO_CHAR(A.DEH_DT,'DD/MM/RRRR'), NULL ) FROM OT_DAK_ENTRY_HEA
D A,OT_DAK_ENTRY_DETL B,OT_FIRM_NAME_APPR_HEAD C WHERE A.DEH_SY
S_ID = B.DED_DEH_SYS_ID AND B.DED_DAK_SYS_ID = C.FNAH_DED_SYS_I
D AND C.FNAH_SYS_ID = (SELECT MAX(B.FNAH_SYS_ID) FROM OT_FIR
198,343 2 99,171.5 8.8 5.82 46.25 1414719916
UPDATE OM_MEM_REG_HEAD SET MRH_MRN=:b1 WHERE MRH_SYS_ID = :b2
198,343 2 99,171.5 8.8 5.81 46.10 1414796677
UPDATE OT_DAK_ACTV_HISTORY SET DAH_REG_NO = :B1 WHERE DAH_REG_NO
= :B3 AND TRUNC(DAH_ACTV_ED_DT ) <= TRUNC(:B2 ) AND DAH_ACTV_ST
ATUS = 'C'
173,892 2 86,946.0 7.7 13.85 16.34 3262067067
SELECT STUD_SRN,STUD_FIRST_NAME,STUD_MIDDLE_NAME,STUD_MAIDEN_NAM
E,STUD_SURNAME,STUD_FATHER_NAME,STUD_BIRTH_DT,STUD_COMM_CODE,STU
D_SEX,STUD_HANDICAPPED_YN,STUD_HANDICAPPED_REASON,STUD_LANG_CODE
,STUD_NATIONALITY_CODE,STUD_EMAIL,STUD_PERMNT_ADDR_LINE_1,STUD_P
ERMNT_ADDR_LINE_2,STUD_PERMNT_ADDR_LINE_3,STUD_PERMNT_ADDR_LINE_
112,038 9 12,448.7 5.0 9.23 10.14 2058267852
SELECT ROWID,STUD_DT,STUD_TXN_CODE,STUD_NO,STUD_AMD_NO,STUD_REF_
FROM,STUD_REF_TXN_CODE,STUD_REF_NO,STUD_TEMP_REF_NO,STUD_SRN,STU
D_TITLE,STUD_STATUS,STUD_FIRST_NAME,STUD_MIDDLE_NAME,STUD_SURNAM
E,STUD_MAIDEN_NAME,STUD_NAME_STATUS,STUD_FATHER_NAME,STUD_NATION
ALITY_CODE,STUD_NATION_PROOF_ENCL_YN,STUD_SEX,STUD_HANDICAPPED_Y
102,583 1 102,583.0 4.5 4.51 285.99 802587273
SELECT ROWID,DEH_DT,DEH_TXN_CODE,DEH_NO,DEH_AMD_NO,DEH_REF_FROM,
DEH_REF_TXN_CODE,DEH_REF_NO,DEH_REF_SYS_ID,DEH_REGION_CODE,DEH_A
PPLICATION_DT,DEH_DOC_STATUS,DEH_STATUS,DEH_PRINT_STATUS,DEH_CLO
STATUS,DEHSYS_ID,DEH_COMP_CODE,DEH_ACNT_YR,DEH_AMD_DT,DEH_AMD_
UID,DEH_AMD_RES_CODE,DEH_REF_FROM_NUM,DEH_CR_UID,DEH_CR_DT,DEH_U
98,825 3 32,941.7 4.4 6.70 6.66 2078892348
/*SELECT STUD_SRN
Q1_RE
GNO, O_GET_OLD_REG_NO(STUD_SRN, :BP_COURSE) OLD_NO, TIT_NAME||'
'||STUD_FIRST_NAME||' '||STUD_MIDDLE_NAME||' '||STUD_SURNAME
Q1_NAME, LTRIM(RTRIM(A.STUD_CORRES_ADDR_LINE_1 ))||DECO
96,187 2 48,093.5 4.3 10.78 16.53 3301514821
SELECT MFCD_PAYIN_SLIP_NO MFCD_PAYIN_SLIP_NO
, DECODE(MFCD_BANK_CODE ,'ICI',1,2) ICI_FIRST
, DECODE(MFCD_INSTR_TYPE,'S',1,'L
SQL ordered by Reads for DB: ICAI Instance: icai Snaps: 70 -73
-> End Disk Reads Threshold: 1000
CPU Elapsd
Physical Reads Executions Reads per Exec %Total Time (s) Time (s) Hash Value
',2,'O',3,4) TYPE_FIRST , MFCD_PAYIN_SLIP_DT , FM_BANK
.BANK_NAME , BAD_ADDR1 ADD1
80,683 4 20,170.8 3.6 9.90 54.25 937031003
SELECT TRIM(STUD_SRN)
Q1_REGNO, TR
IM(STUD_TEMP_REF_NO)
Q1_TEMPNO, STUD_TITLE
77,972 8 9,746.5 3.5 8.92 8.84 2241526944
SELECT ROWID,STUD_DT,STUD_TXN_CODE,STUD_NO,STUD_AMD_NO,STUD_REF_
FROM,STUD_REF_TXN_CODE,STUD_REF_NO,STUD_TEMP_REF_NO,STUD_SRN,STU
D_TITLE,STUD_STATUS,STUD_FIRST_NAME,STUD_MIDDLE_NAME,STUD_SURNAM
E,STUD_MAIDEN_NAME,STUD_NAME_STATUS,STUD_FATHER_NAME,STUD_NATION
ALITY_CODE,STUD_NATION_PROOF_ENCL_YN,STUD_SEX,STUD_HANDICAPPED_Y
75,667 3 25,222.3 3.4 3.34 25.09 3345305231
SELECT DISTINCT SFCH_STUD_SRN FROM OT_STUDENT_FEE_COL_HEAD A,O
T_STUDENT_FEE_COL_DETL B WHERE B.SFCD_SFCH_SYS_ID = A.SFCH_SYS_
ID AND B.SFCD_INSTR_BANK_CODE = :b1 AND B.SFCD_INSTR_NO = :b2
72,658 52 1,397.3 3.2 20.32 21.85 4142254844
SELECT LTRIM(RTRIM(DECODE(TIT_NAME,'MR.','CA.','MS.','CA.','MRS.
','CA.') || ' ' || MRH_FIRST_NAME || ' ' || MRH_MIDDLE_NAME
|| ' ' || MRH_SUR_NAME || ' ' || DECODE(MRH_APPR_UID, NULL ,
NULL ,DECODE(MRH_MEM_STATUS,2, NULL ,DECODE(MRH_FELLOW_STATUS_YN
,'Y','FCA','ACA'))) || DECODE(MRH_RESI_STATUS,'A','
48,619 3 16,206.3 2.2 4.19 4.11 496772197
SELECT ROWID,STUD_DT,STUD_TXN_CODE,STUD_NO,STUD_AMD_NO,STUD_REF_
FROM,STUD_REF_TXN_CODE,STUD_REF_NO,STUD_TEMP_REF_NO,STUD_SRN,STU
D_TITLE,STUD_STATUS,STUD_FIRST_NAME,STUD_MIDDLE_NAME,STUD_SURNAM
E,STUD_MAIDEN_NAME,STUD_NAME_STATUS,STUD_FATHER_NAME,STUD_NATION
ALITY_CODE,STUD_NATION_PROOF_ENCL_YN,STUD_SEX,STUD_HANDICAPPED_Y
48,063 230 209.0 2.1 20.27 20.76 1838125769
SELECT MRH_DT,MRH_FIRST_NAME,MRH_MIDDLE_NAME,MRH_SUR_NAME,MRH_ST
ATUS FROM OM_MEM_REG_HEAD WHERE DECODE(:b1,1,MRH_MRN,MRH_MFCH
SQL ordered by Executions for DB: ICAI Instance: icai Snaps: 70 -73
-> End Executions Threshold: 100
CPU per Elap per
Executions Rows Processed Rows per Exec Exec (s) Exec (s) Hash Value
38,614 38,614 1.0 0.00 0.00 1741347688
SELECT SYSDATE FROM SYS.DUAL
12,490 12,488 1.0 0.00 0.00 2614155871
SELECT DECODE(:b1,'L',DECODE(:b2,'ENG',STATUS_NAME,STATUS_BL_NAM
E),DECODE(:b2,'ENG',STATUS_SHORT_NAME,STATUS_BL_SHORT_NAME)) STA
TUS_DESC,STATUS_FRZ_FLAG_NUM FROM OM_STATUS WHERE STATUS_CODE
= :b4
8,629 8,628 1.0 0.00 0.00 1644340447
SELECT DECODE(:b1,'L',DECODE(:b2,'ENG',FEE_TYPE_NAME,FEE_TYPE_BL
NAME),DECODE(:b2,'ENG',FEETYPE_SHORT_NAME,FEE_TYPE_BL_SHORT_NA
ME)) FEE_NAME,FEE_TYPE_FRZ_FLAG_NUM FROM OM_FEE_TYPE WHERE FE
E_TYPE_CODE = :b4
7,275 7,272 1.0 0.00 0.34 3716207873
update seq$ set increment$=:2,minvalue=:3,maxvalue=:4,cycle#=:5,
order$=:6,cache=:7,highwater=:8,audit$=:9,flags=:10 where obj#=:
1
6,293 6,283 1.0 0.00 0.00 2804237544
SELECT DECODE(:b1,'L',DECODE(:b2,'ENG',CITY_NAME,CITY_BL_NAME),D
ECODE(:b2,'ENG',CITY_SHORT_NAME,CITY_BL_SHORT_NAME)) CITY_NAME,C
ITY_TALUK_CODE,CITY_DIST_CODE,CITY_STATE_CODE,CITY_REGION_CODE,C
ITY_FRZ_FLAG_NUM FROM OM_CITY WHERE CITY_CODE = :b4
6,221 6,221 1.0 0.00 0.00 484036617
SELECT DAH_SYS_ID.NEXTVAL FROM DUAL
6,221 6,221 1.0 0.00 0.00 2945494810
SELECT COUNT(DAH_SYS_ID) FROM OT_DAK_ACTV_HISTORY WHERE DAH_ACTV
TYPE = :B2 AND DAHTXN_SYS_ID = :B1
5,979 5,979 1.0 0.00 0.00 35936114
SELECT STUD_DOC_STATUS FROM OM_STUDENT_HEAD WHERE STUD_SYS_ID
= :b1
4,637 4,637 1.0 0.00 0.00 1237293873
SELECT DECODE(:b1,'L',DECODE(:b2,'ENG',COU_NAME,COU_BL_NAME),DEC
ODE(:b2,'ENG',COU_SHORT_NAME,COU_BL_SHORT_NAME)) COU_NAME,COU_FR
Z_FLAG_NUM FROM OM_COUNTRY WHERE COU_CODE = :b4
4,404 1,276 0.3 0.00 0.00 1829426463
SELECT NVL(TAU_FROM_VALUE,0), NVL(TAU_TO_VALUE,0) FROM IM_TXN_AU
TH_USER WHERE TAU_TA_TYPE = :B3 AND TAU_TXN_CODE = :B2 AND TAU_A
UTH_UID = :B1
4,220 4,220 1.0 0.00 0.00 1006906503
UPDATE OT_DAK_ACTV_HISTORY SET DAH_ACTV_ED_DT = :B3 , DAH_ACTV_S
TATUS = 'C' WHERE DAH_ACTV_TYPE = :B2 AND DAH_TXN_SYS_ID = :B1
3,874 66 0.0 0.00 0.00 4284733339
SELECT TIT_NAME ||' '|| AR_FIRST_NAME||' '||AR_MIDDLE_NAME||' '|
|AR_SUR_NAME FROM OT_ARTICLE_REGISTRATION, OM_TITLE WHERE TRIM(A
SQL ordered by Executions for DB: ICAI Instance: icai Snaps: 70 -73
-> End Executions Threshold: 100
Maybe you are looking for
-
Network not showing up, internet works ok
I have a NetGear router and just bought my first Macbook. I have every PC/Tivo connected to this netgear router wired and/or wireless. I'm running a Macbook with Mac OS x 10.5. Try as I might, I can't get this @$%ing computer to see my PCs. My PCs ca
-
Movies in iPad`s Photos app are suddenly put in separate events
Recently I have noticed that the movies i the Photos app are put in separate events, although with the same name as the original event containing the pictures. In iPhoto the structure is fine. I have tried to delete the iPod photos cache and resync,
-
IMac went out and won't come back on
I ask this question on behalf of my father who doens't live in the same town as me. He was at his computer (iMac, 21.5 inch screen, OSX Mountain Lion 10.8.4) during a thunderstorm and it suddenly went out. He said there was a flash of light and then
-
I bank by the internet. I upgraded to Firefox 4.0, and my bank indicates it does not accept this version of Firefox. Also, I was using 4.0 to order some products over the internet, and noticed that the "padlock" indicating a secure(encrypted) connect
-
I had the misfortune of experiencing a dead HD and having to pay for data retrieval. Now my internal HD is randomly ejecting itself. Someone suggested using an online data backup service. As a pro multimedia producer, I'll need 4 TB (at least) of sto