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

Similar Messages

  • 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:
    HAGGAR

    Make 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

  • 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 error

    hi,
    i am having oracle 11gR1 in windows 2003 server. i got the below mentioned error very frequently. I was having 4 redolog groups with 2 member each. After surfing in internet and discussion i have added 4 new groups of redo log with 2 member each. After adding i dint get the below error till now.
    Thread 1 cannot allocate new log, sequence 11813
    Checkpoint not complete
    Current log# 1 seq# 11812 mem# 0: D:\APP\ADMINISTRATOR\ORADATA\ORCL\REDO01.LOG
    Thread 1 advanced to log sequence 11813
    Current log# 2 seq# 11813 mem# 0: D:\APP\ADMINISTRATOR\ORADATA\ORCL\REDO02.LOG
    Thread 1 cannot allocate new log, sequence 11814
    Is that the perfect solution??????????????????????????????
    i am also a bit confused on why this error is occuring can any one explain me?????
    Is there any other solution for this error?????
    Thanks in advance

    Hi,
    You need to find a proper balance between the number of redo log groups, the redo size and eventually the speed of the storage used to store the redo log files.
    By adding more redo log groups, you actually "delay" the moment when the redo log group will need to be re-used (goes round-robin).
    At the same time, increasing the size of your redo logs will also increase the "loop back" time, but too large redo logs can / will increase recovery in case of instance crash.
    Increasing the number of ARCn processes may also help.
    Is that the perfect solution??????????????????????????????If you find one, let it be known!!
    But you can of course find a proper balance. Some tests based on knowledge you can gain from documentation is a "perfect" start.
    i am also a bit confused on why this error is occuring can any one explain me?????SB's post was more than clear enough
    HTH,
    Thierry

  • 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 NOARCHIVELOG mode

    Hi,
    This is first time I am seeing this. In my 11.1.0.7 development database on SOLARIS, I see checkpoint not complete message in alert log file and my database is running in NOARCHIVELOG mode. Can any expert throw light on this that why this warning is there even in NOARCHIVELOG mode?
    Salman

    871174 wrote:
    Hi,
    This is first time I am seeing this. In my 11.1.0.7 development database on SOLARIS, I see checkpoint not complete message in alert log file and my database is running in NOARCHIVELOG mode. Can any expert throw light on this that why this warning is there even in NOARCHIVELOG mode?
    Salman,
    The error doesn't have any relation to the archive log or no archive log mode of the database but to the size of the redo log files of yours and some other factors. The error basically means that you are not able to checkpoint your last current redo quickly enough before it can be reused. What's the size of the redo log files of yours?
    Aman....

  • 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

  • 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

  • "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.

  • 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
    Pratheej

    Anand... 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 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 complete

    You 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.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                           

  • DG Observer triggering SIGSEGV Address not mapped to object errors in alert log

    Hi,
    I've got a Data Guard configuration using two 11.2.0.3 single instance databases.  The configuration has been configured for automatic failover and I have an observer running on a separate box.
    This fast-start failover configuration has been in place for about a month and in the last week, numerous SEGSEGV (address not mapped to object) errors are reported in the alert log.  This is happening quite frequently (every 4/5 minutes or so).
    The corresponding trace files show the process triggering the error coming from the observer.
    Has anyone experienced this problem?  I'm at my wits end trying to figure out how to fix the configuration to eliminate this error.
    I must also note that even though this error is occurring a lot, it doesn't seem to be affecting any of the database functionality.
    Help?
    Thanks in advance.
    Beth

    Hi..   The following is the alert log message, the traced file generated, and the current values of the data guard configuration.  In addition, as part of my research, I attempted to apply patch 12615660 which did not take care of the issue.  I also set the inbound_connection_timeout parameter to 0 and that didn't help either.  I'm still researching but any pointer in the right direction is very much appreciated.
    Error in Alert Log
    Thu Apr 09 10:28:59 2015
    Exception [type: SIGSEGV, Address not mapped to object] [ADDR:0x9] [PC:0x85CE503, nstimexp()+71] [flags: 0x0, count: 1]
    Errors in file /u01/app/oracle/diag/rdbms/<db_unq_name>/<SID>/trace/<SID>_ora_29902.trc  (incident=69298):
    ORA-07445: exception encountered: core dump [nstimexp()+71] [SIGSEGV] [ADDR:0x9] [PC:0x85CE503] [Address not mapped to object] []
    Use ADRCI or Support Workbench to package the incident.
    See Note 411.1 at My Oracle Support for error and packaging details.
    Thu Apr 09 10:29:02 2015
    Sweep [inc][69298]: completed
    Trace file:
    Trace file /u01/app/oracle/diag/rdbms/<db_unq_name>/<SID>/trace/<SID>_ora_29902.trc
    Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production
    With the Partitioning and Oracle Label Security options
    ORACLE_HOME = /u01/app/oracle/product/11.2.0.3/dbhome_1
    System name:    Linux
    Node name:      <host name>
    Release:        2.6.32-431.17.1.el6.x86_64
    Version:        #1 SMP Wed May 7 14:14:17 CDT 2014
    Machine:        x86_64
    Instance name: <SID>
    Redo thread mounted by this instance: 1
    Oracle process number: 19
    Unix process pid: 29902, image: oracle@<host name>
    *** 2015-04-09 10:28:59.966
    *** SESSION ID:(416.127) 2015-04-09 10:28:59.966
    *** CLIENT ID:() 2015-04-09 10:28:59.966
    *** SERVICE NAME:(<db_unq_name>) 2015-04-09 10:28:59.966
    *** MODULE NAME:(dgmgrl@<observer host> (TNS V1-V3)) 2015-04-09 10:28:59.966
    *** ACTION NAME:() 2015-04-09 10:28:59.966
    Exception [type: SIGSEGV, Address not mapped to object] [ADDR:0x9] [PC:0x85CE503, nstimexp()+71] [flags: 0x0, count: 1]
    DDE: Problem Key 'ORA 7445 [nstimexp()+71]' was flood controlled (0x6) (incident: 69298)
    ORA-07445: exception encountered: core dump [nstimexp()+71] [SIGSEGV] [ADDR:0x9] [PC:0x85CE503] [Address not mapped to object] []
    ssexhd: crashing the process...
    Shadow_Core_Dump = PARTIAL
    ksdbgcra: writing core file to directory '/u01/app/oracle/diag/rdbms/<db_unq_name>/<SID>/cdump'
    Data Guard Configuration
    DGMGRL> show configuration verbose;
    Configuration - dg_config
      Protection Mode: MaxPerformance
      Databases:
        dbprim - Primary database
        dbstby - (*) Physical standby database
      (*) Fast-Start Failover target
      Properties:
        FastStartFailoverThreshold      = '30'
        OperationTimeout                = '30'
        FastStartFailoverLagLimit       = '180'
        CommunicationTimeout            = '180'
        FastStartFailoverAutoReinstate  = 'TRUE'
        FastStartFailoverPmyShutdown    = 'TRUE'
        BystandersFollowRoleChange      = 'ALL'
    Fast-Start Failover: ENABLED
      Threshold:        30 seconds
      Target:           dbstby
      Observer:         observer_host
      Lag Limit:        180 seconds
      Shutdown Primary: TRUE
      Auto-reinstate:   TRUE
    Configuration Status:
    SUCCESS
    DGMGRL> show database verbose dbprim
    Database - dbprim
      Role:            PRIMARY
      Intended State:  TRANSPORT-ON
      Instance(s):
        DG_CONFIG
      Properties:
        DGConnectIdentifier             = 'dbprim'
        ObserverConnectIdentifier       = ''
        LogXptMode                      = 'ASYNC'
        DelayMins                       = '0'
        Binding                         = 'optional'
        MaxFailure                      = '0'
        MaxConnections                  = '1'
        ReopenSecs                      = '300'
        NetTimeout                      = '30'
        RedoCompression                 = 'DISABLE'
        LogShipping                     = 'ON'
        PreferredApplyInstance          = ''
        ApplyInstanceTimeout            = '0'
        ApplyParallel                   = 'AUTO'
        StandbyFileManagement           = 'MANUAL'
        ArchiveLagTarget                = '0'
        LogArchiveMaxProcesses          = '4'
        LogArchiveMinSucceedDest        = '1'
        DbFileNameConvert               = ''
        LogFileNameConvert              = ''
        FastStartFailoverTarget         = 'dbstby'
        InconsistentProperties          = '(monitor)'
        InconsistentLogXptProps         = '(monitor)'
        SendQEntries                    = '(monitor)'
        LogXptStatus                    = '(monitor)'
        RecvQEntries                    = '(monitor)'
        SidName                         = ‘<sid>’
        StaticConnectIdentifier         = '(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=<db host name>)(PORT=1521))(CONNECT_DATA=(SERVICE_NAME=<service_name>)(INSTANCE_NAME=<sid>)(SERVER=DEDICATED)))'
        StandbyArchiveLocation          = 'USE_DB_RECOVERY_FILE_DEST'
        AlternateLocation               = ''
        LogArchiveTrace                 = '0'
        LogArchiveFormat                = '%t_%s_%r.dbf'
        TopWaitEvents                   = '(monitor)'
    Database Status:
    SUCCESS
    DGMGRL> show database verbose dbstby
    Database - dbstby
      Role:            PHYSICAL STANDBY
      Intended State:  APPLY-ON
      Transport Lag:   0 seconds
      Apply Lag:       0 seconds
      Real Time Query: ON
      Instance(s):
        DG_CONFIG
      Properties:
        DGConnectIdentifier             = 'dbstby'
        ObserverConnectIdentifier       = ''
        LogXptMode                      = 'ASYNC'
        DelayMins                       = '0'
        Binding                         = 'optional'
        MaxFailure                      = '0'
        MaxConnections                  = '1'
        ReopenSecs                      = '300'
        NetTimeout                      = '30'
        RedoCompression                 = 'DISABLE'
        LogShipping                     = 'ON'
        PreferredApplyInstance          = ''
        ApplyInstanceTimeout            = '0'
        ApplyParallel                   = 'AUTO'
        StandbyFileManagement           = 'AUTO'
        ArchiveLagTarget                = '0'
        LogArchiveMaxProcesses          = '4'
        LogArchiveMinSucceedDest        = '1'
        DbFileNameConvert               = ''
        LogFileNameConvert              = ''
        FastStartFailoverTarget         = 'dbprim'
        InconsistentProperties          = '(monitor)'
        InconsistentLogXptProps         = '(monitor)'
        SendQEntries                    = '(monitor)'
        LogXptStatus                    = '(monitor)'
        RecvQEntries                    = '(monitor)'
        SidName                         = ‘<sid>’
        StaticConnectIdentifier         = '(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=<db host name>)(PORT=1521))(CONNECT_DATA=(SERVICE_NAME=<service_name>)(INSTANCE_NAME=<sid>)(SERVER=DEDICATED)))'
        StandbyArchiveLocation          = 'USE_DB_RECOVERY_FILE_DEST'
        AlternateLocation               = ''
        LogArchiveTrace                 = '0'
        LogArchiveFormat                = '%t_%s_%r.dbf'
        TopWaitEvents                   = '(monitor)'
    Database Status:
    SUCCESS

  • 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 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.
    thxs

    when 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

Maybe you are looking for

  • Webinar: Unified Business Process Management

    <b>SAP NetWeaver Know-How Network Webinar:  Unified Business Process Management Wednesday 28 July 2004 11 a.m. EDT</b> On Wednesday 28 July, George Yu hosts the webinar titled <b>Unified Business Process Management</b> as part of the ongoing SAP NetW

  • Arch Linux Carbon Wallpaper

    Hi everyone, just wanted to share this wallpaper I made with GIMP, following a tutorial I found on abduzeedo.com (or http://abduzeedo.com/rawz-light-effects-photoshop, to be more specific), a blog for graphics design. The tutorial was originally inte

  • Repeat Regions inside Repeat Regions

    I'm not sure how to do this.  Dreamweaver says you can't put server behaviors inside server behaviors.   But it seems like a pretty standard thing someone might want to do.  For instance: Let's say you wanted to create an online menu.  And say...you

  • Ford USB doesn't recognize iPhone anymore

    While driving today using my iphone's iPod via USB on my 2009 Ford Escape the music stopped and I eventually restarted the phone. The car never recognized the iPod again. I went the the Apple store and eventually they replaced the phone. Even before

  • CRM Marketing product listing interface

    HI All, We have a requirment to propose products for customer by default, for that we have created a condition type in Marketing product listing. Some custom table /CN/*CUS90003 is created while creating the conition type. Now our requirment is to pe