Control file parallel write

Hi,
From my statspack report one of the top wait events is control file parallel write.
               Wait Time
Event          Time     Percentage Avg. wait
Control file      11000     3.61% 11.68
parallel write
How can I tune the control file parallel write event?
Right now for this instance I have control file multiplexed onto
3 different drives L. M. N
Thanks

If you are doing excessive log swaps, you could be generating too many checkpoints. See how many log swaps you have done in v$loghist. It is also possible to reduce the number of writes to log files by adding the /*+ APPEND */ hint and the "nologging" to insert statements to reduce the amount of log files filled.
I have also combined update and delete statements to generate fewer writes to the log files.
You can recreate the log files larger with :
alter database drop logfile group 3;
ALTER DATABASE ADD LOGFILE THREAD 1 GROUP 3 '/oracle/oradata/CURACAO9/redo03.log' size 500m reuse;
ALTER DATABASE ADD LOGFILE member '/oracle/oradata/CURACAO9/redo03b.log' reuse to GROUP 3;
alter system switch logfile;
alter system checkpoint;
alter database drop logfile group 2; -- and do group 2 etc.

Similar Messages

  • Wait Events "log file parallel write" / "log file sync" during CREATE INDEX

    Hello guys,
    at my current project i am performing some performance tests for oracle data guard. The question is "How does a LGWR SYNC transfer influences the system performance?"
    To get some performance values, that i can compare i just built up a normal oracle database in the first step.
    Now i am performing different tests like creating "large" indexes, massive parallel inserts/commits, etc. to get the bench mark.
    My database is an oracle 10.2.0.4 with multiplexed redo log files on AIX.
    I am creating an index on a "normal" table .. i execute "dbms_workload_repository.create_snapshot()" before and after the CREATE INDEX to get an equivalent timeframe for the AWR report.
    After the index is built up (round about 9 GB) i perform an awrrpt.sql to get the AWR report.
    And now take a look at these values from the AWR
                                                                       Avg
                                                 %Time  Total Wait    wait     Waits
    Event                                 Waits  -outs    Time (s)    (ms)      /txn
    log file parallel write              10,019     .0         132      13      33.5
    log file sync                           293     .7           4      15       1.0
    ......How can this be possible?
    Regarding to the documentation
    -> log file sync: http://download.oracle.com/docs/cd/B19306_01/server.102/b14237/waitevents003.htm#sthref3120
    Wait Time: The wait time includes the writing of the log buffer and the post.-> log file parallel write: http://download.oracle.com/docs/cd/B19306_01/server.102/b14237/waitevents003.htm#sthref3104
    Wait Time: Time it takes for the I/Os to complete. Even though redo records are written in parallel, the parallel write is not complete until the last I/O is on disk.This was also my understanding .. the "log file sync" wait time should be higher than the "log file parallel write" wait time, because of it includes the I/O and the response time to the user session.
    I could accept it, if the values are close to each other (maybe round about 1 second in total) .. but the different between 132 seconds and 4 seconds is too noticeable.
    Is the behavior of the log file sync/write different when performing a DDL like CREATE INDEX (maybe async .. like you can influence it with the initialization parameter COMMIT_WRITE??)?
    Do you have any idea how these values come about?
    Any thoughts/ideas are welcome.
    Thanks and Regards

    Surachart Opun (HunterX) wrote:
    Thank you for Nice Idea.
    In this case, How can we reduce "log file parallel write" and "log file sync" waited time?
    CREATE INDEX with NOLOGGINGA NOLOGGING can help, can't it?Yes - if you create index nologging then you wouldn't be generating that 10GB of redo log, so the waits would disappear.
    Two points on nologging, though:
    <ul>
    it's "only" an index, so you could always rebuild it in the event of media corruption, but if you had lots of indexes created nologging this might cause an unreasonable delay before the system was usable again - so you should decide on a fallback option, such as taking a new backup of the tablespace as soon as all the nologging operatons had completed.
    If the database, or that tablespace, is in +"force logging"+ mode, the nologging will not work.
    </ul>
    Don't get too alarmed by the waits, though. My guess is that the +"log file sync"+ waits are mostly from other sessions, and since there aren't many of them the other sessions are probably not seeing a performance issue. The +"log file parallel write"+ waits are caused by your create index, but they are happeninng to lgwr in the background which is running concurrently with your session - so your session is not (directly) affected by them, so may not be seeing a performance issue.
    The other sessions are seeing relatively high sync times because their log file syncs have to wait for one of the large writes that you have triggered to complete, and then the logwriter includes their (little) writes with your next (large) write.
    There may be a performance impact, though, from the pure volume of I/O. Apart from the I/O to write the index you have LGWR writting (N copies) of the redo for the index and ARCH is reading and writing the completed log files caused by the index build. So the 9GB of index could easily be responsible for vastly more I/O than the initial 9GB.
    Regards
    Jonathan Lewis
    http://jonathanlewis.wordpress.com
    http://www.jlcomp.demon.co.uk
    To post code, statspack/AWR report, execution plans or trace files, start and end the section with the tag {noformat}{noformat} (lowercase, curly brackets, no spaces) so that the text appears in fixed format.
    "Science is more than a body of knowledge; it is a way of thinking"
    Carl Sagan                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                           

  • Log file parallel write

    Hi,
    on 11g R2. I have the following :
    SQL> select  total_waits, time_waited from v$system_event where event='log file parallel write';
    TOTAL_WAITS TIME_WAITED
          74144       28100Is it too much or not ? These valuses , to what should be compared ?
    Thank you.

    Hi,
    thanks to all.
    Here is checkpoint frequency from my alertlog :
    Wed May  9 23:01:14 2012
    Thread 1 advanced to log sequence 14 (LGWR switch)
      Current log# 2 seq# 14 mem# 0: /index01/bases/MYDB/redo02.log
    Thu May 10 02:14:27 2012
    Thread 1 cannot allocate new log, sequence 15
    Private strand flush not complete
      Current log# 2 seq# 14 mem# 0: /index01/bases/MYDB/redo02.log
    Thu May 10 02:14:29 2012
    Thread 1 advanced to log sequence 15 (LGWR switch)
      Current log# 3 seq# 15 mem# 0: /index01/bases/MYDB/redo03.log
    Thu May 10 02:14:29 2012
    ALTER SYSTEM ARCHIVE LOG
    Thu May 10 02:14:29 2012
    Thread 1 advanced to log sequence 16 (LGWR switch)
      Current log# 1 seq# 16 mem# 0: /index01/bases/MYDB/redo01.log No I do not know log advisor. Where is it ?
    Karan,
    thank for your interesting remarks.
    I usually have created DBs without enough attention to REDOLOG file size. I decided to verify on the most recent of my DBs. I found that query and issued it. For me it is not enough but I wanted to understand.
    Regards.

  • Log file sync vs log file parallel write probably not bug 2669566

    This is a continuation of a previous thread about ‘log file sync’ and ‘log file parallel write’ events.
    Version : 9.2.0.8
    Platform : Solaris
    Application : Oracle Apps
    The number of commits per second ranges between 10 and 30.
    When querying statspack performance data the calculated average wait time on the event ‘log file sync’ is on average 10 times the wait time for the ‘log file parallel write’ event.
    Below just 2 samples where the ratio is even about 20.
    "snap_time"     " log file parallel write avg"     "log file sync avg"     "ratio
    11/05/2008 10:38:26      8,142     156,343     19.20
    11/05/2008 10:08:23     8,434     201,915     23.94
    So the wait time for a ‘log file sync’ is 10 times the wait time for a ‘log file parallel write’.
    First I thought that I was hitting bug 2669566.
    But then Jonathan Lewis is blog pointed me to Tanel Poder’s snapper tool.
    And I think that it proves that I am NOT hitting this bug.
    Below is a sample of the output for the log writer.
    -- End of snap 3
    HEAD,SID, SNAPSHOT START ,SECONDS,TYPE,STATISTIC , DELTA, DELTA/SEC, HDELTA, HDELTA/SEC
    DATA, 4, 20081105 10:35:41, 30, STAT, messages sent , 1712, 57, 1.71k, 57.07
    DATA, 4, 20081105 10:35:41, 30, STAT, messages received , 866, 29, 866, 28.87
    DATA, 4, 20081105 10:35:41, 30, STAT, background timeouts , 10, 0, 10, .33
    DATA, 4, 20081105 10:35:41, 30, STAT, redo wastage , 212820, 7094, 212.82k, 7.09k
    DATA, 4, 20081105 10:35:41, 30, STAT, redo writer latching time , 2, 0, 2, .07
    DATA, 4, 20081105 10:35:41, 30, STAT, redo writes , 867, 29, 867, 28.9
    DATA, 4, 20081105 10:35:41, 30, STAT, redo blocks written , 33805, 1127, 33.81k, 1.13k
    DATA, 4, 20081105 10:35:41, 30, STAT, redo write time , 652, 22, 652, 21.73
    DATA, 4, 20081105 10:35:41, 30, WAIT, rdbms ipc message ,23431084, 781036, 23.43s, 781.04ms
    DATA, 4, 20081105 10:35:41, 30, WAIT, log file parallel write , 6312957, 210432, 6.31s, 210.43ms
    DATA, 4, 20081105 10:35:41, 30, WAIT, LGWR wait for redo copy , 18749, 625, 18.75ms, 624.97us
    When adding the DELTA/SEC (which is in micro seconds) for the wait events it always roughly adds up to a million micro seconds.
    In the example above 781036 + 210432 = 991468 micro seconds.
    This is the case for all the snaps taken by snapper.
    So I think that the wait time for the ‘log file parallel write time’ must be more or less correct.
    So I still have the question “Why is the ‘log file sync’ about 10 times the time of the ‘log file parallel write’?”
    Any clues?

    Yes that is true!
    But that is the way I calculate the average wait time = total wait time / total waits
    So the average wait time for the event 'log file sync' per wait should be near the wait time for the 'llog file parallel write' event.
    I use the query below:
    select snap_id
    , snap_time
    , event
    , time_waited_micro
    , (time_waited_micro - p_time_waited_micro)/((snap_time - p_snap_time) * 24) corrected_wait_time_h
    , total_waits
    , (total_waits - p_total_waits)/((snap_time - p_snap_time) * 24) corrected_waits_h
    , trunc(((time_waited_micro - p_time_waited_micro)/((snap_time - p_snap_time) * 24))/((total_waits - p_total_waits)/((snap_time - p_snap_time) * 24))) average
    from (
    select sn.snap_id, sn.snap_time, se.event, se.time_waited_micro, se.total_waits,
    lag(sn.snap_id) over (partition by se.event order by sn.snap_id) p_snap_id,
    lag(sn.snap_time) over (partition by se.event order by sn.snap_time) p_snap_time,
    lag(se.time_waited_micro) over (partition by se.event order by sn.snap_id) p_time_waited_micro,
    lag(se.total_waits) over (partition by se.event order by sn.snap_id) p_total_waits,
    row_number() over (partition by event order by sn.snap_id) r
    from perfstat.stats$system_event se, perfstat.stats$snapshot sn
    where se.SNAP_ID = sn.SNAP_ID
    and se.EVENT = 'log file sync'
    order by snap_id, event
    where time_waited_micro - p_time_waited_micro > 0
    order by snap_id desc;

  • Performance issues - Log file parallel write

    Hi there,
    Since a few months I have big performance issues with my Oracle 11.2.0.1.0.
    If I look in the Enterprise manager (in blocking sessions) I see al lot of "log file paralles writes" and a lot of "log file sync" .
    We have configured an active data guard environment and are using ASM.
    We are not stressing out the database with heavy queries or commits or something, but sometimes during the day this happens on non specific times...
    We've investigated everything (performance to SAN / heavy queries / oracle problems etc etc) and we really don't know what to do anymore so i thought.. let's try a post on the Forum.....
    Perhaps someone had similar things?
    Thanks,
    BR
    Mark

    mwevromans wrote:
    See blow a tail of alertlog.
    Tue Apr 24 15:12:17 2012
    Thread 1 cannot allocate new log, sequence 194085
    Checkpoint not complete
    Current log# 1 seq# 194084 mem# 0: +DATA/kewillprd/onlinelog/group_1.262.712516155
    Current log# 1 seq# 194084 mem# 1: +FRA/kewillprd/onlinelog/group_1.438.756466165
    LGWR: Standby redo logfile selected to archive thread 1 sequence 194085
    LGWR: Standby redo logfile selected for thread 1 sequence 194085 for destination LOG_ARCHIVE_DEST_2
    Thread 1 advanced to log sequence 194085 (LGWR switch)
    Current log# 2 seq# 194085 mem# 0: +DATA/kewillprd/onlinelog/group_2.264.712516155
    Current log# 2 seq# 194085 mem# 1: +FRA/kewillprd/onlinelog/group_2.418.756466215
    Tue Apr 24 15:12:21 2012
    Archived Log entry 388061 added for thread 1 sequence 194084 ID 0x90d7aa62 dest 1:
    Tue Apr 24 15:14:09 2012
    Thread 1 cannot allocate new log, sequence 194086
    Checkpoint not complete
    Current log# 2 seq# 194085 mem# 0: +DATA/kewillprd/onlinelog/group_2.264.712516155
    Current log# 2 seq# 194085 mem# 1: +FRA/kewillprd/onlinelog/group_2.418.756466215
    LGWR: Standby redo logfile selected to archive thread 1 sequence 194086
    LGWR: Standby redo logfile selected for thread 1 sequence 194086 for destination LOG_ARCHIVE_DEST_2
    Thread 1 advanced to log sequence 194086 (LGWR switch)
    Current log# 3 seq# 194086 mem# 0: +DATA/kewillprd/onlinelog/group_3.266.712516155
    Current log# 3 seq# 194086 mem# 1: +FRA/kewillprd/onlinelog/group_3.435.756466241
    Tue Apr 24 15:14:14 2012
    Archived Log entry 388063 added for thread 1 sequence 194085 ID 0x90d7aa62 dest 1:
    Tue Apr 24 15:16:46 2012
    Thread 1 cannot allocate new log, sequence 194087
    Checkpoint not complete
    Current log# 3 seq# 194086 mem# 0: +DATA/kewillprd/onlinelog/group_3.266.712516155
    Current log# 3 seq# 194086 mem# 1: +FRA/kewillprd/onlinelog/group_3.435.756466241
    Thread 1 cannot allocate new log, sequence 194087
    Private strand flush not complete
    Current log# 3 seq# 194086 mem# 0: +DATA/kewillprd/onlinelog/group_3.266.712516155
    Current log# 3 seq# 194086 mem# 1: +FRA/kewillprd/onlinelog/group_3.435.756466241
    LGWR: Standby redo logfile selected to archive thread 1 sequence 194087
    LGWR: Standby redo logfile selected for thread 1 sequence 194087 for destination LOG_ARCHIVE_DEST_2
    Thread 1 advanced to log sequence 194087 (LGWR switch)
    Current log# 1 seq# 194087 mem# 0: +DATA/kewillprd/onlinelog/group_1.262.712516155
    Current log# 1 seq# 194087 mem# 1: +FRA/kewillprd/onlinelog/group_1.438.756466165
    Tue Apr 24 15:16:54 2012
    Archived Log entry 388065 added for thread 1 sequence 194086 ID 0x90d7aa62 dest 1:
    Tue Apr 24 15:18:59 2012
    Thread 1 cannot allocate new log, sequence 194088
    Checkpoint not complete
    Current log# 1 seq# 194087 mem# 0: +DATA/kewillprd/onlinelog/group_1.262.712516155
    Current log# 1 seq# 194087 mem# 1: +FRA/kewillprd/onlinelog/group_1.438.756466165
    Thread 1 cannot allocate new log, sequence 194088
    Private strand flush not complete
    Current log# 1 seq# 194087 mem# 0: +DATA/kewillprd/onlinelog/group_1.262.712516155
    Current log# 1 seq# 194087 mem# 1: +FRA/kewillprd/onlinelog/group_1.438.756466165
    LGWR: Standby redo logfile selected to archive thread 1 sequence 194088
    LGWR: Standby redo logfile selected for thread 1 sequence 194088 for destination LOG_ARCHIVE_DEST_2
    Thread 1 advanced to log sequence 194088 (LGWR switch)
    Current log# 2 seq# 194088 mem# 0: +DATA/kewillprd/onlinelog/group_2.264.712516155
    Current log# 2 seq# 194088 mem# 1: +FRA/kewillprd/onlinelog/group_2.418.756466215
    Tue Apr 24 15:19:06 2012
    Archived Log entry 388067 added for thread 1 sequence 194087 ID 0x90d7aa62 dest 1:
    Tue Apr 24 15:22:00 2012
    Thread 1 cannot allocate new log, sequence 194089
    Checkpoint not complete
    Current log# 2 seq# 194088 mem# 0: +DATA/kewillprd/onlinelog/group_2.264.712516155
    Current log# 2 seq# 194088 mem# 1: +FRA/kewillprd/onlinelog/group_2.418.756466215
    Thread 1 cannot allocate new log, sequence 194089
    Private strand flush not complete
    Current log# 2 seq# 194088 mem# 0: +DATA/kewillprd/onlinelog/group_2.264.712516155
    Current log# 2 seq# 194088 mem# 1: +FRA/kewillprd/onlinelog/group_2.418.756466215
    LGWR: Standby redo logfile selected to archive thread 1 sequence 194089
    LGWR: Standby redo logfile selected for thread 1 sequence 194089 for destination LOG_ARCHIVE_DEST_2
    Thread 1 advanced to log sequence 194089 (LGWR switch)
    Current log# 3 seq# 194089 mem# 0: +DATA/kewillprd/onlinelog/group_3.266.712516155
    Current log# 3 seq# 194089 mem# 1: +FRA/kewillprd/onlinelog/group_3.435.756466241
    Tue Apr 24 15:19:06 2012
    Archived Log entry 388069 added for thread 1 sequence 194088 ID 0x90d7aa62 dest 1:Hi
    1st switch time ==> Tue Apr 24 15:18:59 2012
    2nd switch time ==> Tue Apr 24 15:19:06 2012
    3rd switch time ==> Tue Apr 24 15:19:06 2012
    Redo log file switch has good impact on the performance of the database. Frequent log switches may lead to the slowness of the database . Oracle documents suggests to resize the redolog files so that log switches happen more like every 15-30 min (roughly depending on the architecture and recovery requirements).
    AS i check the alertlog file and find that the log are switchinh very fequent which is one of the reason that you are getting checkpoint  not complete message . i have face this issue many times and i generally increase the size of the logfile and set the archive_lag_time parameter as i have suggested above . If you further want to go root cause and more details then above guys will help you more because i don't have much experience in database tunning . If you looking for aworkarounf then you must go through it .
    Good Luck
    --neeraj                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                       

  • 'log file sync' versus 'log file prallel write'

    I have been asked to run an artificial test that performs a large number of small insert-only transactions with a high degree (200) of parallelism. The COMMITS were not inside a PL/SQL loop so a 'log file sync' (LFS) event occured each COMMIT. I have measured the average 'log file parallel write' (LFPW) time by running the following PL/SQL queries at the beginning and end of a 10 second period:
    SELECT time_waited,
    total_waits
    INTO wait_start_lgwr,
    wait_start_lgwr_c
    FROM v$system_event e
    WHERE event LIKE 'log%parallel%';
    SELECT time_waited,
    total_waits
    INTO wait_end_lgwr,
    wait_end_lgwr_c
    FROM v$system_event e
    WHERE event LIKE 'log%parallel%';
    I took the difference in TIME_WAITED and divided it by the difference in TOTAL_WAITS.
    I did the same thing for LFS.
    What I expected was that the LFS time would be just over 50% more than the LFPW time: when the thread commits it has to wait for the previous LFPW to complete (on average half way through) and then for its own.
    Now I know there is a lot of CPU related stuff that goes on in LGWR but I 'reniced' it to a higher priority and could observe that it was then spending 90% of its time in LFPW, 10% ON CPU and no time idle. Total system CPU time averaged only 25% on this 64 'processor' machine.
    What I saw was that the LFS time was substantially more than the LFPW time. For example, on one test LFS was 18.07ms and LFPW was 6.56ms.
    When I divided the number of bytes written each time by the average 'commit size' it seems that LGWR is writing out data for only about one third of the average number of transactions in LFS state (rather than the two thirds that I would have expected). When the COMMIT was changed to COMMIT WORK NOWAIT the size of each LFPW increased substantially.
    These observations are at odds with my understanding of how LGWR works. My understanding is that when LGWR completes one LFPW it begins a new one with the entire contents of the log buffer at that time.
    Can anybody tell me what I am missing?
    P.S. Same results in database versions 10.2 Sun M5000 and 11.2 HP G7s.

    I have been asked to run an artificial test that performs a large number of small insert-only transactions with a high degree (200) of parallelism. The COMMITS were not inside a PL/SQL loop so a 'log file sync' (LFS) event occured each COMMIT. I have measured the average 'log file parallel write' (LFPW) time by running the following PL/SQL queries at the beginning and end of a 10 second period:
    SELECT time_waited,
    total_waits
    INTO wait_start_lgwr,
    wait_start_lgwr_c
    FROM v$system_event e
    WHERE event LIKE 'log%parallel%';
    SELECT time_waited,
    total_waits
    INTO wait_end_lgwr,
    wait_end_lgwr_c
    FROM v$system_event e
    WHERE event LIKE 'log%parallel%';
    I took the difference in TIME_WAITED and divided it by the difference in TOTAL_WAITS.
    I did the same thing for LFS.
    What I expected was that the LFS time would be just over 50% more than the LFPW time: when the thread commits it has to wait for the previous LFPW to complete (on average half way through) and then for its own.
    Now I know there is a lot of CPU related stuff that goes on in LGWR but I 'reniced' it to a higher priority and could observe that it was then spending 90% of its time in LFPW, 10% ON CPU and no time idle. Total system CPU time averaged only 25% on this 64 'processor' machine.
    What I saw was that the LFS time was substantially more than the LFPW time. For example, on one test LFS was 18.07ms and LFPW was 6.56ms.
    When I divided the number of bytes written each time by the average 'commit size' it seems that LGWR is writing out data for only about one third of the average number of transactions in LFS state (rather than the two thirds that I would have expected). When the COMMIT was changed to COMMIT WORK NOWAIT the size of each LFPW increased substantially.
    These observations are at odds with my understanding of how LGWR works. My understanding is that when LGWR completes one LFPW it begins a new one with the entire contents of the log buffer at that time.
    Can anybody tell me what I am missing?
    P.S. Same results in database versions 10.2 Sun M5000 and 11.2 HP G7s.

  • Error on write to control file

    Hi all,
         We are using the database sever version Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - Prod
    working with windows platform. I saw an error in Alert log as follows,
    ORA-00221: error on write to control file
    Instance terminated by CKPT, pid = 4300
    Few mins later the database opened without error.
         Please anyone suggest me the cause and Solution for this error
    Regards,
    Jai.

    hi,
    Error: ORA 221
    Text: error on write to control file
    Cause: An error occurred when writing to one or more of the control files.
    Action: See accompanying messages.
    can you please post further errors.
    Specific to windows is there any firewalls enabled & antivirus?
    Thanks

  • Who writes LOG SEQUENCE NUMBER to CONTROL FILE,whether CKPT or LGWR process

    I am in confusion that,
    When log switch occurs that time Log sequence no. is generated by LGWR. then after who writes that LSN to CONTROL FILE whether Checkpoint or LGWR.
    Please provide me proper answer with example.....

    I notice by using fuser on a controlfile on hp-ux, a number of processes keep the controlfile open.  So it would make sense that the one that writes logs would write log sequence numbers to the controlfile too.
    $ for z in  `/usr/sbin/fuser  control03.ctl|awk ' {x=split($0,args); for (i=2;i<=x;i++){print args[i]}}'`
            do
                ps -efx|grep $z|grep -v grep
            done
    control03.ctl: oooooooooo
      oracle 27129     1  0  Sep  5  ?        12:15 ora_arc1_TPRD
      oracle 27073     1  0  Sep  5  ?        52:45 ora_dbw0_TPRD
      oracle 27127     1  0  Sep  5  ?        10:52 ora_arc0_TPRD
      oracle  9485     1  0  Nov  3  ?         9:14 oracleTPRD (LOCAL=NO)
      oracle 22395     1  0 08:36:22 ?         0:24 oracleTPRD (LOCAL=NO)
      oracle 27075     1  0  Sep  5  ?        68:53 ora_lgwr_TPRD
      oracle 22116     1  0 08:33:24 ?         1:06 oracleTPRD (LOCAL=NO)
      oracle 27077     1  0  Sep  5  ?        41:05 ora_ckpt_TPRD
      oracle 26510     1  0  Nov 30  ?        21:26 oracleTPRD (LOCAL=NO)

  • Help needed to write control file.

    Hi Guys,
    i need to write one control file to upload data from .txt file to oracle table.
    .txt file data contains like this
    2006041110:40:22
    2006041111:30:42
    2006041210:40:22
    i need to upload this data into date column in oracle table.
    please help me to write control file for this requirement.
    Thanks for your help and time

        data1        "to_date(:data1, 'YYYYMMDDHH24:MI:SS')"

  • How to write control file below data

    Hi,
    Here is my table
    create table sample1 (name varchar2(5), num number(2));
    sample.txt(Datafile)
    vikram12
    sharma13
    sonu 14
    Here is my control file
    load data
    infile 'C:\sample.txt'
    into table sample1
    fields terminated by "," optionally enclosed by '"'          
    ( name char(5), num char(2) )
    But it rejecting all the records. Just let me know where i went wrong.
    Thanks in advance

    fields terminated by "," optionally enclosed by
    '"'          As per your control file, the fields have to be seperated by commas but in your datafile it is seperated by space. Either change the delimiter in your control file or in your datafile
    Using Comma Seperated file,
    sample.txt(Datafile)
    vikram,12
    sharma,13
    sonu, 14
    load data
    infile 'C:\sample.txt'
    into table sample1
    fields terminated by ","
    optionally enclosed by '"'
    ( name char(5),
    num char(2)
    )Note:
    1. You have to increase the length of name column as your datafile has values greater than 5 characters. First and second records will be rejected with NAME VARCHAR2(5)

  • Control File issue

    Hi All,
    11.2.0.1 on AIX 7.1 and Level 0 happens on every SATURDAY and L1 backup run every day.
    We are using following script for level0 RMAN backup:
    RUN {
    SHOW ALL;
    CONFIGURE DEVICE TYPE DISK BACKUP TYPE TO COMPRESSED BACKUPSET PARALLELISM 4;
    CONFIGURE RETENTION POLICY TO REDUNDANCY 1;
    ALLOCATE CHANNEL ch1 TYPE DISK;
    ALLOCATE CHANNEL ch2 TYPE DISK;
    ALLOCATE CHANNEL ch3 TYPE DISK;
    ALLOCATE CHANNEL ch4 TYPE DISK;
    BACKUP FORMAT '/oraclebackup/HFM11PROD/DF_L0_%d_%D%M%Y_%u_%s_%p' INCREMENTAL LEVEL 0 AS COMPRESSED BACKUPSET DATABASE TAG='LEVEL0';
    BACKUP FORMAT '/oraclebackup/HFM11PROD/ARC_L0_%d_%D%M%Y_%u_%s_%p'   ARCHIVELOG ALL NOT BACKED UP 2 TIMES TAG='LEVEL0';
    BACKUP FORMAT '/oraclebackup/HFM11PROD/CF_L0_%d_%D%M%Y_%u_%s_%p' CURRENT CONTROLFILE TAG='LEVEL0';
    BACKUP FORMAT '/oraclebackup/HFM11PROD/SP_L0_%d_%D%M%Y_%u_%s_%p' SPFILE TAG='LEVEL0';
    CROSSCHECK ARCHIVELOG ALL;
    DELETE NOPROMPT OBSOLETE;
    RELEASE CHANNEL ch1;
    RELEASE CHANNEL ch2;
    RELEASE CHANNEL ch3;
    RELEASE CHANNEL ch4;
    }Now backup logs shows that we have backup of control file in two backup pieces : One implicitly in a backup piece DF_L0_HFM11PRD_10112012_l8npv5b6_13992_1
    and other one is explicitly in CF_L0_HFM11PRD_10112012_lhnpv62e_14001_1 .
    RMAN> RUN {
    2> SHOW ALL;
    3> CONFIGURE DEVICE TYPE DISK BACKUP TYPE TO COMPRESSED BACKUPSET PARALLELISM 4;
    4> CONFIGURE RETENTION POLICY TO REDUNDANCY 1;
    5> ALLOCATE CHANNEL ch1 TYPE DISK;
    6> ALLOCATE CHANNEL ch2 TYPE DISK;
    7> ALLOCATE CHANNEL ch3 TYPE DISK;
    8> ALLOCATE CHANNEL ch4 TYPE DISK;
    9> BACKUP FORMAT '/oraclebackup/HFM11PROD/DF_L0_%d_%D%M%Y_%u_%s_%p' INCREMENTAL LEVEL 0 AS COMPRESSED BACKUPSET DATABASE TAG='LEVEL0';
    10> BACKUP FORMAT '/oraclebackup/HFM11PROD/ARC_L0_%d_%D%M%Y_%u_%s_%p'   ARCHIVELOG ALL NOT BACKED UP 2 TIMES TAG='LEVEL0';
    11> BACKUP FORMAT '/oraclebackup/HFM11PROD/CF_L0_%d_%D%M%Y_%u_%s_%p' CURRENT CONTROLFILE TAG='LEVEL0';
    12> BACKUP FORMAT '/oraclebackup/HFM11PROD/SP_L0_%d_%D%M%Y_%u_%s_%p' SPFILE TAG='LEVEL0';
    13> CROSSCHECK ARCHIVELOG ALL;
    14> DELETE NOPROMPT OBSOLETE;
    15> RELEASE CHANNEL ch1;
    16> RELEASE CHANNEL ch2;
    17> RELEASE CHANNEL ch3;
    18> RELEASE CHANNEL ch4;
    19> }
    RMAN configuration parameters for database with db_unique_name HFM11PRD are:
    CONFIGURE RETENTION POLICY TO REDUNDANCY 1;
    CONFIGURE BACKUP OPTIMIZATION OFF; # default
    CONFIGURE DEFAULT DEVICE TYPE TO DISK; # default
    CONFIGURE CONTROLFILE AUTOBACKUP OFF; # default
    CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO '%F'; # default
    CONFIGURE DEVICE TYPE DISK BACKUP TYPE TO COMPRESSED BACKUPSET PARALLELISM 4;
    CONFIGURE DATAFILE BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default
    CONFIGURE ARCHIVELOG BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default
    CONFIGURE MAXSETSIZE TO UNLIMITED; # default
    CONFIGURE ENCRYPTION FOR DATABASE OFF; # default
    CONFIGURE ENCRYPTION ALGORITHM 'AES128'; # default
    CONFIGURE COMPRESSION ALGORITHM 'BASIC' AS OF RELEASE 'DEFAULT' OPTIMIZE FOR LOAD TRUE ; # default
    CONFIGURE ARCHIVELOG DELETION POLICY TO NONE; # default
    CONFIGURE SNAPSHOT CONTROLFILE NAME TO '/u01/app/orahyp_p/product/11.2/dbs/snapcf_HFM11PRD.f'; # default
    old RMAN configuration parameters:
    CONFIGURE DEVICE TYPE DISK BACKUP TYPE TO COMPRESSED BACKUPSET PARALLELISM 4;
    new RMAN configuration parameters:
    CONFIGURE DEVICE TYPE DISK BACKUP TYPE TO COMPRESSED BACKUPSET PARALLELISM 4;
    new RMAN configuration parameters are successfully stored
    starting full resync of recovery catalog
    full resync complete
    old RMAN configuration parameters:
    CONFIGURE RETENTION POLICY TO REDUNDANCY 1;
    new RMAN configuration parameters:
    CONFIGURE RETENTION POLICY TO REDUNDANCY 1;
    new RMAN configuration parameters are successfully stored
    starting full resync of recovery catalog
    full resync complete
    allocated channel: ch1
    channel ch1: SID=1210 device type=DISK
    allocated channel: ch2
    channel ch2: SID=1477 device type=DISK
    allocated channel: ch3
    channel ch3: SID=66 device type=DISK
    allocated channel: ch4
    channel ch4: SID=1156 device type=DISK
    Starting backup at 10-NOV-12
    channel ch1: starting compressed incremental level 0 datafile backup set
    channel ch1: specifying datafile(s) in backup set
    input datafile file number=00001 name=/u04/oradata/HFM11PRD/system01.dbf
    input datafile file number=00008 name=/u04/oradata/HFM11PRD/EPM_HFM4.DBF
    input datafile file number=00012 name=/u04/oradata/HFM11PRD/EPM_HFM8.DBF
    input datafile file number=00017 name=/u04/oradata/HFM11PRD/EPM_HFM12.DBF
    input datafile file number=00004 name=/u04/oradata/HFM11PRD/EPM_HSS1.DBF
    input datafile file number=00020 name=/u04/oradata/HFM11PRD/EPM_HFM3.DBF
    channel ch1: starting piece 1 at 10-NOV-12
    channel ch2: starting compressed incremental level 0 datafile backup set
    channel ch2: specifying datafile(s) in backup set
    input datafile file number=00003 name=/u04/oradata/HFM11PRD/undots01.dbf
    input datafile file number=00009 name=/u04/oradata/HFM11PRD/EPM_HFM5.DBF
    input datafile file number=00013 name=/u04/oradata/HFM11PRD/EPM_HFM9.DBF
    input datafile file number=00018 name=/u04/oradata/HFM11PRD/EPM_HFM13.DBF
    input datafile file number=00005 name=/u04/oradata/HFM11PRD/EPM_BI1.DBF
    input datafile file number=00021 name=/u04/oradata/HFM11PRD/EPM_HFM15.DBF
    channel ch2: starting piece 1 at 10-NOV-12
    channel ch3: starting compressed incremental level 0 datafile backup set
    channel ch3: specifying datafile(s) in backup set
    input datafile file number=00007 name=/u04/oradata/HFM11PRD/EPM_HFM2.DBF
    input datafile file number=00011 name=/u04/oradata/HFM11PRD/EPM_HFM7.DBF
    input datafile file number=00016 name=/u04/oradata/HFM11PRD/EPM_HFM11.DBF
    input datafile file number=00002 name=/u04/oradata/HFM11PRD/sysaux01.dbf
    input datafile file number=00022 name=/u04/oradata/HFM11PRD/EPM_HSS_new1.DBF
    channel ch3: starting piece 1 at 10-NOV-12
    channel ch4: starting compressed incremental level 0 datafile backup set
    channel ch4: specifying datafile(s) in backup set
    input datafile file number=00006 name=/u04/oradata/HFM11PRD/EPM_HFM1.DBF
    input datafile file number=00010 name=/u04/oradata/HFM11PRD/EPM_HFM6.DBF
    input datafile file number=00015 name=/u04/oradata/HFM11PRD/EPM_HFM10.DBF
    input datafile file number=00019 name=/u04/oradata/HFM11PRD/EPM_HFM14.DBF
    input datafile file number=00014 name=/u04/oradata/HFM11PRD/userdata01.dbf
    channel ch4: starting piece 1 at 10-NOV-12
    channel ch2: finished piece 1 at 10-NOV-12
    _*piece handle=/oraclebackup/HFM11PROD/DF_L0_HFM11PRD_10112012_l8npv5b6_13992_1 tag=LEVEL0 comment=NONE*_
    channel ch2: backup set complete, elapsed time: 00:10:46
    channel ch2: starting compressed incremental level 0 datafile backup set
    channel ch2: specifying datafile(s) in backup set
    _*including current control file in backup set*channel ch2: starting piece 1 at 10-NOV-12_
    channel ch2: finished piece 1 at 10-NOV-12
    piece handle=/oraclebackup/HFM11PROD/DF_L0_HFM11PRD_10112012_lbnpv5vc_13995_1 tag=LEVEL0 comment=NONE
    channel ch2: backup set complete, elapsed time: 00:00:01
    channel ch2: starting compressed incremental level 0 datafile backup set
    channel ch2: specifying datafile(s) in backup set
    including current SPFILE in backup set
    channel ch2: starting piece 1 at 10-NOV-12
    channel ch2: finished piece 1 at 10-NOV-12
    piece handle=/oraclebackup/HFM11PROD/DF_L0_HFM11PRD_10112012_lcnpv5ve_13996_1 tag=LEVEL0 comment=NONE
    channel ch2: backup set complete, elapsed time: 00:00:01
    channel ch1: finished piece 1 at 10-NOV-12
    piece handle=/oraclebackup/HFM11PROD/DF_L0_HFM11PRD_10112012_l7npv5b6_13991_1 tag=LEVEL0 comment=NONE
    channel ch1: backup set complete, elapsed time: 00:11:03
    channel ch4: finished piece 1 at 10-NOV-12
    piece handle=/oraclebackup/HFM11PROD/DF_L0_HFM11PRD_10112012_lanpv5b7_13994_1 tag=LEVEL0 comment=NONE
    channel ch4: backup set complete, elapsed time: 00:11:32
    channel ch3: finished piece 1 at 10-NOV-12
    piece handle=/oraclebackup/HFM11PROD/DF_L0_HFM11PRD_10112012_l9npv5b6_13993_1 tag=LEVEL0 comment=NONE
    channel ch3: backup set complete, elapsed time: 00:11:52
    Finished backup at 10-NOV-12
    Starting backup at 10-NOV-12
    current log archived
    channel ch1: starting compressed archived log backup set
    channel ch1: specifying archived log(s) in backup set
    input archived log thread=1 sequence=40007 RECID=40001 STAMP=798971664
    input archived log thread=1 sequence=40008 RECID=40002 STAMP=798972711
    input archived log thread=1 sequence=40009 RECID=40003 STAMP=798973470
    input archived log thread=1 sequence=40010 RECID=40004 STAMP=798974835
    input archived log thread=1 sequence=40011 RECID=40005 STAMP=798975943
    channel ch1: starting piece 1 at 10-NOV-12
    channel ch2: starting compressed archived log backup set
    channel ch2: specifying archived log(s) in backup set
    input archived log thread=1 sequence=40012 RECID=40006 STAMP=798976804
    input archived log thread=1 sequence=40013 RECID=40007 STAMP=798977866
    input archived log thread=1 sequence=40014 RECID=40008 STAMP=798978754
    input archived log thread=1 sequence=40015 RECID=40009 STAMP=798980083
    input archived log thread=1 sequence=40016 RECID=40010 STAMP=798981194
    channel ch2: starting piece 1 at 10-NOV-12
    channel ch3: starting compressed archived log backup set
    channel ch3: specifying archived log(s) in backup set
    input archived log thread=1 sequence=40017 RECID=40011 STAMP=798982283
    input archived log thread=1 sequence=40018 RECID=40012 STAMP=798983171
    input archived log thread=1 sequence=40019 RECID=40013 STAMP=798984077
    input archived log thread=1 sequence=40020 RECID=40014 STAMP=798985146
    input archived log thread=1 sequence=40021 RECID=40015 STAMP=798985212
    channel ch3: starting piece 1 at 10-NOV-12
    channel ch4: starting compressed archived log backup set
    channel ch4: specifying archived log(s) in backup set
    input archived log thread=1 sequence=40022 RECID=40016 STAMP=798985214
    input archived log thread=1 sequence=40023 RECID=40017 STAMP=798985992
    input archived log thread=1 sequence=40024 RECID=40018 STAMP=798987561
    input archived log thread=1 sequence=40025 RECID=40019 STAMP=798988338
    channel ch4: starting piece 1 at 10-NOV-12
    channel ch4: finished piece 1 at 10-NOV-12
    piece handle=/oraclebackup/HFM11PROD/ARC_L0_HFM11PRD_10112012_lgnpv61k_14000_1 tag=LEVEL0 comment=NONE
    channel ch4: backup set complete, elapsed time: 00:00:15
    channel ch1: finished piece 1 at 10-NOV-12
    piece handle=/oraclebackup/HFM11PROD/ARC_L0_HFM11PRD_10112012_ldnpv61j_13997_1 tag=LEVEL0 comment=NONE
    channel ch1: backup set complete, elapsed time: 00:00:26
    channel ch2: finished piece 1 at 10-NOV-12
    piece handle=/oraclebackup/HFM11PROD/ARC_L0_HFM11PRD_10112012_lenpv61j_13998_1 tag=LEVEL0 comment=NONE
    channel ch2: backup set complete, elapsed time: 00:00:26
    channel ch3: finished piece 1 at 10-NOV-12
    piece handle=/oraclebackup/HFM11PROD/ARC_L0_HFM11PRD_10112012_lfnpv61j_13999_1 tag=LEVEL0 comment=NONE
    channel ch3: backup set complete, elapsed time: 00:00:25
    Finished backup at 10-NOV-12
    Starting backup at 10-NOV-12
    channel ch1: starting compressed full datafile backup set
    channel ch1: specifying datafile(s) in backup set
    _*including current control file in backup set*_
    channel ch1: starting piece 1 at 10-NOV-12
    channel ch1: finished piece 1 at 10-NOV-12
    _*piece handle=/oraclebackup/HFM11PROD/CF_L0_HFM11PRD_10112012_lhnpv62e_14001_1 tag=LEVEL0 comment=NONE*_channel ch1: backup set complete, elapsed time: 00:00:01
    Finished backup at 10-NOV-12
    Starting backup at 10-NOV-12
    channel ch1: starting compressed full datafile backup set
    channel ch1: specifying datafile(s) in backup set
    including current SPFILE in backup set
    channel ch1: starting piece 1 at 10-NOV-12
    channel ch1: finished piece 1 at 10-NOV-12
    piece handle=/oraclebackup/HFM11PROD/SP_L0_HFM11PRD_10112012_linpv62i_14002_1 tag=LEVEL0 comment=NONE
    channel ch1: backup set complete, elapsed time: 00:00:01
    Finished backup at 10-NOV-12Following is the script of Leve 1 RMAN backup.
    RUN {
    SHOW ALL;
    CONFIGURE DEVICE TYPE DISK BACKUP TYPE TO COMPRESSED BACKUPSET PARALLELISM 4;
    ALLOCATE CHANNEL ch1 TYPE DISK;
    ALLOCATE CHANNEL ch2 TYPE DISK;
    ALLOCATE CHANNEL ch3 TYPE DISK;
    ALLOCATE CHANNEL ch4 TYPE DISK;
    BACKUP FORMAT '/oraclebackup/HFM11PROD/DF_L1_%d_%D%M%Y_%u_%s_%p' INCREMENTAL LEVEL 1 AS COMPRESSED BACKUPSET DATABASE TAG='LEVEL1';
    BACKUP FORMAT '/oraclebackup/HFM11PROD/ARC_L1_%d_%D%M%Y_%u_%s_%p'   ARCHIVELOG ALL NOT BACKED UP 2 TIMES TAG='LEVEL1';
    CROSSCHECK ARCHIVELOG ALL;
    DELETE NOPROMPT OBSOLETE;
    RELEASE CHANNEL ch1;
    RELEASE CHANNEL ch2;
    RELEASE CHANNEL ch3;
    RELEASE CHANNEL ch4;
    }Following is the log from Level 1 backup which shows that it has marked the backup of control file in backup piece CF_L0_HFM11PRD_10112012_lhnpv62e_14001_1 as obsolete and deleted.
    RMAN> RUN {
    2> SHOW ALL;
    3> CONFIGURE DEVICE TYPE DISK BACKUP TYPE TO COMPRESSED BACKUPSET PARALLELISM 4;
    4> ALLOCATE CHANNEL ch1 TYPE DISK;
    5> ALLOCATE CHANNEL ch2 TYPE DISK;
    6> ALLOCATE CHANNEL ch3 TYPE DISK;
    7> ALLOCATE CHANNEL ch4 TYPE DISK;
    8> BACKUP FORMAT '/oraclebackup/HFM11PROD/DF_L1_%d_%D%M%Y_%u_%s_%p' INCREMENTAL LEVEL 1 AS COMPRESSED BACKUPSET DATABASE TAG='LEVEL1';
    9> BACKUP FORMAT '/oraclebackup/HFM11PROD/ARC_L1_%d_%D%M%Y_%u_%s_%p'   ARCHIVELOG ALL NOT BACKED UP 2 TIMES TAG='LEVEL1';
    10> CROSSCHECK ARCHIVELOG ALL;
    11> DELETE NOPROMPT OBSOLETE;
    12> RELEASE CHANNEL ch1;
    13> RELEASE CHANNEL ch2;
    14> RELEASE CHANNEL ch3;
    15> RELEASE CHANNEL ch4;
    16> }
    RMAN configuration parameters for database with db_unique_name HFM11PRD are:
    CONFIGURE RETENTION POLICY TO REDUNDANCY 1;
    CONFIGURE BACKUP OPTIMIZATION OFF; # default
    CONFIGURE DEFAULT DEVICE TYPE TO DISK; # default
    CONFIGURE CONTROLFILE AUTOBACKUP OFF; # default
    CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO '%F'; # default
    CONFIGURE DEVICE TYPE DISK BACKUP TYPE TO COMPRESSED BACKUPSET PARALLELISM 4;
    CONFIGURE DATAFILE BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default
    CONFIGURE ARCHIVELOG BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default
    CONFIGURE MAXSETSIZE TO UNLIMITED; # default
    CONFIGURE ENCRYPTION FOR DATABASE OFF; # default
    CONFIGURE ENCRYPTION ALGORITHM 'AES128'; # default
    CONFIGURE COMPRESSION ALGORITHM 'BASIC' AS OF RELEASE 'DEFAULT' OPTIMIZE FOR LOAD TRUE ; # default
    CONFIGURE ARCHIVELOG DELETION POLICY TO NONE; # default
    CONFIGURE SNAPSHOT CONTROLFILE NAME TO '/u01/app/orahyp_p/product/11.2/dbs/snapcf_HFM11PRD.f'; # default
    old RMAN configuration parameters:
    CONFIGURE DEVICE TYPE DISK BACKUP TYPE TO COMPRESSED BACKUPSET PARALLELISM 4;
    new RMAN configuration parameters:
    CONFIGURE DEVICE TYPE DISK BACKUP TYPE TO COMPRESSED BACKUPSET PARALLELISM 4;
    new RMAN configuration parameters are successfully stored
    starting full resync of recovery catalog
    full resync complete
    allocated channel: ch1
    channel ch1: SID=1718 device type=DISK
    allocated channel: ch2
    channel ch2: SID=1499 device type=DISK
    allocated channel: ch3
    channel ch3: SID=119 device type=DISK
    allocated channel: ch4
    channel ch4: SID=1166 device type=DISK
    Starting backup at 12-NOV-12
    channel ch1: starting compressed incremental level 1 datafile backup set
    channel ch1: specifying datafile(s) in backup set
    input datafile file number=00001 name=/u04/oradata/HFM11PRD/system01.dbf
    input datafile file number=00008 name=/u04/oradata/HFM11PRD/EPM_HFM4.DBF
    input datafile file number=00012 name=/u04/oradata/HFM11PRD/EPM_HFM8.DBF
    input datafile file number=00017 name=/u04/oradata/HFM11PRD/EPM_HFM12.DBF
    input datafile file number=00004 name=/u04/oradata/HFM11PRD/EPM_HSS1.DBF
    input datafile file number=00020 name=/u04/oradata/HFM11PRD/EPM_HFM3.DBF
    channel ch1: starting piece 1 at 12-NOV-12
    channel ch2: starting compressed incremental level 1 datafile backup set
    channel ch2: specifying datafile(s) in backup set
    input datafile file number=00003 name=/u04/oradata/HFM11PRD/undots01.dbf
    input datafile file number=00009 name=/u04/oradata/HFM11PRD/EPM_HFM5.DBF
    input datafile file number=00013 name=/u04/oradata/HFM11PRD/EPM_HFM9.DBF
    input datafile file number=00018 name=/u04/oradata/HFM11PRD/EPM_HFM13.DBF
    input datafile file number=00005 name=/u04/oradata/HFM11PRD/EPM_BI1.DBF
    input datafile file number=00021 name=/u04/oradata/HFM11PRD/EPM_HFM15.DBF
    channel ch2: starting piece 1 at 12-NOV-12
    channel ch3: starting compressed incremental level 1 datafile backup set
    channel ch3: specifying datafile(s) in backup set
    input datafile file number=00007 name=/u04/oradata/HFM11PRD/EPM_HFM2.DBF
    input datafile file number=00011 name=/u04/oradata/HFM11PRD/EPM_HFM7.DBF
    input datafile file number=00016 name=/u04/oradata/HFM11PRD/EPM_HFM11.DBF
    input datafile file number=00002 name=/u04/oradata/HFM11PRD/sysaux01.dbf
    input datafile file number=00022 name=/u04/oradata/HFM11PRD/EPM_HSS_new1.DBF
    channel ch3: starting piece 1 at 12-NOV-12
    channel ch4: starting compressed incremental level 1 datafile backup set
    channel ch4: specifying datafile(s) in backup set
    input datafile file number=00006 name=/u04/oradata/HFM11PRD/EPM_HFM1.DBF
    input datafile file number=00010 name=/u04/oradata/HFM11PRD/EPM_HFM6.DBF
    input datafile file number=00015 name=/u04/oradata/HFM11PRD/EPM_HFM10.DBF
    input datafile file number=00019 name=/u04/oradata/HFM11PRD/EPM_HFM14.DBF
    input datafile file number=00014 name=/u04/oradata/HFM11PRD/userdata01.dbf
    channel ch4: starting piece 1 at 12-NOV-12
    channel ch1: finished piece 1 at 12-NOV-12
    piece handle=/oraclebackup/HFM11PROD/DF_L1_HFM11PRD_12112012_lvnq4e3a_14015_1 tag=LEVEL1 comment=NONE
    channel ch1: backup set complete, elapsed time: 00:01:36
    channel ch1: starting compressed incremental level 1 datafile backup set
    channel ch1: specifying datafile(s) in backup set
    channel ch4: finished piece 1 at 12-NOV-12
    piece handle=/oraclebackup/HFM11PROD/DF_L1_HFM11PRD_12112012_m2nq4e3a_14018_1 tag=LEVEL1 comment=NONE
    channel ch4: backup set complete, elapsed time: 00:01:35
    channel ch4: starting compressed incremental level 1 datafile backup set
    channel ch4: specifying datafile(s) in backup set
    including current SPFILE in backup set
    channel ch4: starting piece 1 at 12-NOV-12
    including current control file in backup set
    channel ch1: starting piece 1 at 12-NOV-12
    channel ch1: finished piece 1 at 12-NOV-12
    piece handle=/oraclebackup/HFM11PROD/DF_L1_HFM11PRD_12112012_m3nq4e6a_14019_1 tag=LEVEL1 comment=NONE
    channel ch1: backup set complete, elapsed time: 00:00:01
    channel ch4: finished piece 1 at 12-NOV-12
    piece handle=/oraclebackup/HFM11PROD/DF_L1_HFM11PRD_12112012_m4nq4e6a_14020_1 tag=LEVEL1 comment=NONE
    channel ch4: backup set complete, elapsed time: 00:00:01
    channel ch3: finished piece 1 at 12-NOV-12
    piece handle=/oraclebackup/HFM11PROD/DF_L1_HFM11PRD_12112012_m1nq4e3a_14017_1 tag=LEVEL1 comment=NONE
    channel ch3: backup set complete, elapsed time: 00:01:39
    channel ch2: finished piece 1 at 12-NOV-12
    piece handle=/oraclebackup/HFM11PROD/DF_L1_HFM11PRD_12112012_m0nq4e3a_14016_1 tag=LEVEL1 comment=NONE
    channel ch2: backup set complete, elapsed time: 00:02:41
    Finished backup at 12-NOV-12
    Starting backup at 12-NOV-12
    current log archived
    channel ch1: starting compressed archived log backup set
    channel ch1: specifying archived log(s) in backup set
    input archived log thread=1 sequence=40201 RECID=40195 STAMP=799144567
    input archived log thread=1 sequence=40202 RECID=40196 STAMP=799145383
    input archived log thread=1 sequence=40203 RECID=40197 STAMP=799146296
    input archived log thread=1 sequence=40204 RECID=40198 STAMP=799147040
    input archived log thread=1 sequence=40205 RECID=40199 STAMP=799147640
    input archived log thread=1 sequence=40206 RECID=40200 STAMP=799148271
    channel ch1: starting piece 1 at 12-NOV-12
    channel ch2: starting compressed archived log backup set
    channel ch2: specifying archived log(s) in backup set
    input archived log thread=1 sequence=40207 RECID=40201 STAMP=799149018
    input archived log thread=1 sequence=40208 RECID=40202 STAMP=799150009
    input archived log thread=1 sequence=40209 RECID=40203 STAMP=799150549
    input archived log thread=1 sequence=40210 RECID=40204 STAMP=799151041
    input archived log thread=1 sequence=40211 RECID=40205 STAMP=799151860
    input archived log thread=1 sequence=40212 RECID=40206 STAMP=799152535
    channel ch2: starting piece 1 at 12-NOV-12
    channel ch3: starting compressed archived log backup set
    channel ch3: specifying archived log(s) in backup set
    input archived log thread=1 sequence=40213 RECID=40207 STAMP=799153553
    input archived log thread=1 sequence=40214 RECID=40208 STAMP=799153980
    input archived log thread=1 sequence=40215 RECID=40209 STAMP=799154283
    input archived log thread=1 sequence=40216 RECID=40210 STAMP=799155243
    input archived log thread=1 sequence=40217 RECID=40211 STAMP=799155964
    input archived log thread=1 sequence=40218 RECID=40212 STAMP=799156899
    channel ch3: starting piece 1 at 12-NOV-12
    channel ch4: starting compressed archived log backup set
    channel ch4: specifying archived log(s) in backup set
    input archived log thread=1 sequence=40219 RECID=40213 STAMP=799157722
    input archived log thread=1 sequence=40220 RECID=40214 STAMP=799158015
    input archived log thread=1 sequence=40221 RECID=40215 STAMP=799158018
    input archived log thread=1 sequence=40222 RECID=40216 STAMP=799158847
    input archived log thread=1 sequence=40223 RECID=40217 STAMP=799159640
    input archived log thread=1 sequence=40224 RECID=40218 STAMP=799160590
    channel ch4: starting piece 1 at 12-NOV-12
    channel ch4: finished piece 1 at 12-NOV-12
    piece handle=/oraclebackup/HFM11PROD/ARC_L1_HFM11PRD_12112012_m8nq4e8h_14024_1 tag=LEVEL1 comment=NONE
    channel ch4: backup set complete, elapsed time: 00:00:25
    channel ch1: finished piece 1 at 12-NOV-12
    piece handle=/oraclebackup/HFM11PROD/ARC_L1_HFM11PRD_12112012_m5nq4e8g_14021_1 tag=LEVEL1 comment=NONE
    channel ch1: backup set complete, elapsed time: 00:00:36
    channel ch2: finished piece 1 at 12-NOV-12
    piece handle=/oraclebackup/HFM11PROD/ARC_L1_HFM11PRD_12112012_m6nq4e8g_14022_1 tag=LEVEL1 comment=NONE
    channel ch2: backup set complete, elapsed time: 00:00:36
    channel ch3: finished piece 1 at 12-NOV-12
    piece handle=/oraclebackup/HFM11PROD/ARC_L1_HFM11PRD_12112012_m7nq4e8g_14023_1 tag=LEVEL1 comment=NONE
    channel ch3: backup set complete, elapsed time: 00:00:35
    Finished backup at 12-NOV-12
    validation succeeded for archived log
    archived log file name=/u05/oradata/HFM11PRD/HFM11PRD_402011737949656.ARC RECID=40195 STAMP=799144567
    validation succeeded for archived log
    archived log file name=/u05/oradata/HFM11PRD/HFM11PRD_402021737949656.ARC RECID=40196 STAMP=799145383
    validation succeeded for archived log
    archived log file name=/u05/oradata/HFM11PRD/HFM11PRD_402031737949656.ARC RECID=40197 STAMP=799146296
    validation succeeded for archived log
    archived log file name=/u05/oradata/HFM11PRD/HFM11PRD_402041737949656.ARC RECID=40198 STAMP=799147040
    validation succeeded for archived log
    archived log file name=/u05/oradata/HFM11PRD/HFM11PRD_402051737949656.ARC RECID=40199 STAMP=799147640
    validation succeeded for archived log
    archived log file name=/u05/oradata/HFM11PRD/HFM11PRD_402061737949656.ARC RECID=40200 STAMP=799148271
    validation succeeded for archived log
    archived log file name=/u05/oradata/HFM11PRD/HFM11PRD_402071737949656.ARC RECID=40201 STAMP=799149018
    validation succeeded for archived log
    archived log file name=/u05/oradata/HFM11PRD/HFM11PRD_402081737949656.ARC RECID=40202 STAMP=799150009
    validation succeeded for archived log
    archived log file name=/u05/oradata/HFM11PRD/HFM11PRD_402091737949656.ARC RECID=40203 STAMP=799150549
    validation succeeded for archived log
    archived log file name=/u05/oradata/HFM11PRD/HFM11PRD_402101737949656.ARC RECID=40204 STAMP=799151041
    validation succeeded for archived log
    archived log file name=/u05/oradata/HFM11PRD/HFM11PRD_402111737949656.ARC RECID=40205 STAMP=799151860
    validation succeeded for archived log
    archived log file name=/u05/oradata/HFM11PRD/HFM11PRD_402121737949656.ARC RECID=40206 STAMP=799152535
    validation succeeded for archived log
    archived log file name=/u05/oradata/HFM11PRD/HFM11PRD_402131737949656.ARC RECID=40207 STAMP=799153553
    validation succeeded for archived log
    archived log file name=/u05/oradata/HFM11PRD/HFM11PRD_402141737949656.ARC RECID=40208 STAMP=799153980
    validation succeeded for archived log
    archived log file name=/u05/oradata/HFM11PRD/HFM11PRD_402151737949656.ARC RECID=40209 STAMP=799154283
    validation succeeded for archived log
    archived log file name=/u05/oradata/HFM11PRD/HFM11PRD_402161737949656.ARC RECID=40210 STAMP=799155243
    validation succeeded for archived log
    archived log file name=/u05/oradata/HFM11PRD/HFM11PRD_402171737949656.ARC RECID=40211 STAMP=799155964
    validation succeeded for archived log
    archived log file name=/u05/oradata/HFM11PRD/HFM11PRD_402181737949656.ARC RECID=40212 STAMP=799156899
    validation succeeded for archived log
    archived log file name=/u05/oradata/HFM11PRD/HFM11PRD_402191737949656.ARC RECID=40213 STAMP=799157722
    validation succeeded for archived log
    archived log file name=/u05/oradata/HFM11PRD/HFM11PRD_402201737949656.ARC RECID=40214 STAMP=799158015
    validation succeeded for archived log
    archived log file name=/u05/oradata/HFM11PRD/HFM11PRD_402211737949656.ARC RECID=40215 STAMP=799158018
    validation succeeded for archived log
    archived log file name=/u05/oradata/HFM11PRD/HFM11PRD_402221737949656.ARC RECID=40216 STAMP=799158847
    validation succeeded for archived log
    archived log file name=/u05/oradata/HFM11PRD/HFM11PRD_402231737949656.ARC RECID=40217 STAMP=799159640
    validation succeeded for archived log
    archived log file name=/u05/oradata/HFM11PRD/HFM11PRD_402241737949656.ARC RECID=40218 STAMP=799160590
    Crosschecked 24 objects
    RMAN retention policy will be applied to the command
    RMAN retention policy is set to redundancy 1
    Deleting the following obsolete backups and copies:
    Type                 Key    Completion Time    Filename/Handle
    Backup Set           18521832 10-NOV-12        
      Backup Piece       18521838 10-NOV-12          /oraclebackup/HFM11PROD/CF_L0_HFM11PRD_10112012_lhnpv62e_14001_1
    Backup Set           18521846 10-NOV-12        
      Backup Piece       18521848 10-NOV-12          /oraclebackup/HFM11PROD/SP_L0_HFM11PRD_10112012_linpv62i_14002_1
    deleted backup piece
    backup piece handle=/oraclebackup/HFM11PROD/CF_L0_HFM11PRD_10112012_lhnpv62e_14001_1 RECID=14000 STAMP=798988367
    deleted backup piece
    backup piece handle=/oraclebackup/HFM11PROD/SP_L0_HFM11PRD_10112012_linpv62i_14002_1 RECID=14001 STAMP=798988370
    Deleted 2 objects
    released channel: ch1
    released channel: ch2
    released channel: ch3
    released channel: ch4
    RMAN> exit;Now, on Friday when i am trying to do a restore for this database on another server i am getting error as below. Restore script is as below.
    run
    allocate AUXILIARY channel c1 device type disk;
    allocate AUXILIARY channel c2 device type disk;
    allocate AUXILIARY channel c3 device type disk;
    allocate AUXILIARY channel c4 device type disk;
    set until scn 699575816;
    duplicate target database to HFM11TMP;
    release channel c1;
    release channel c2;
    release channel c3;
    release channel c4;
    }Error is as:
       sql clone "alter system set  db_unique_name =
    ''HFM11TMP'' comment=
    ''Modified by RMAN duplicate'' scope=spfile";
       shutdown clone immediate;
       startup clone force nomount
       restore clone primary controlfile;
       alter clone database mount;
    executing Memory Script
    executing command: SET until clause
    sql statement: alter system set  db_name =  ''HFM11PRD'' comment= ''Modified by RMAN duplicate'' scope=spfile
    sql statement: alter system set  db_unique_name =  ''HFM11TMP'' comment= ''Modified by RMAN duplicate'' scope=spfile
    Oracle instance shut down
    Oracle instance started
    Total System Global Area    4275781632 bytes
    Fixed Size                     2213632 bytes
    Variable Size               2298480896 bytes
    Database Buffers            1962934272 bytes
    Redo Buffers                  12152832 bytes
    allocated channel: c1
    channel c1: SID=112 device type=DISK
    Starting restore at 06-NOV-12
    released channel: c1
    RMAN-00571: ===========================================================
    RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
    RMAN-00571: ===========================================================
    RMAN-03002: failure of Duplicate Db command at 11/06/2012 15:13:32
    RMAN-03015: error occurred in stored script Memory Script
    RMAN-06026: some targets not found - aborting restore
    RMAN-06024: no backup or copy of the control file found to restoreRMAN is searching for backup of controlfile in backup piece CF_L0_HFM11PRD_10112012_lhnpv62e_14001_1. But this has been already obsolete.
    Now, if it not possible to get above backup piece back, then how to proceed with restore with backup piece DF_L0_HFM11PRD_10112012_l8npv5b6_13992_1 as it also has control file backup and available on disk, not obsolete. I can understand the reason for marking CF* file as obsolete because of redundency 1. But how to proceed with restore with available backup ?

    Hello;
    I would change my configure for one :
    RMAN>CONFIGURE CONTROLFILE AUTOBACKUP ON;Would use this to check :
    list backup of controlfile completed before <date>And would catalog everything again just to be sure before starting the restore.
    You may have to catalog use the control file piece to avoid the error.
    RMAN> catalog backuppiece ...Another idea is to test the restore using something like this :
    RMAN> run {
            set until time "to_date('2012 NOV 17 07:00','YYYY MON DD HH24:MI')";
            restore controlfile preview;
          }Best Regards
    mseberg
    Edited by: mseberg on Nov 16, 2012 10:12 AM
    Edited by: mseberg on Nov 16, 2012 11:13 AM

  • RAC control file has correpted, unable to mount database

    hi guru's,
    Im trying to startup my rac db, but it giving following error.
    SQL> startup
    ORACLE instance started.
    Total System Global Area 233861120 bytes
    Fixed Size 2212088 bytes
    Variable Size 176164616 bytes
    Database Buffers 50331648 bytes
    Redo Buffers 5152768 bytes
    ORA-00221: error on write to control file
    ORA-00206: error in writing (block 1, # blocks 1) of control file
    ORA-00202: control file: '+CTRL/finance/controlfile/current.256.812371485'
    ORA-15081: failed to submit an I/O operation to a disk
    ORA-15081: failed to submit an I/O operation to a disk
    alert log:
    Errors in file /oradump/oradata/finance/dump/diag/rdbms/finance/finance1/trace/finance1_ora_11821.trc:
    ORA-15080: synchronous I/O operation to a disk failed
    WARNING: failed to write mirror side 1 of virtual extent 0 logical extent 0 of file 256 in group 2 on disk 1 allocation unit 78
    Errors in file /oradump/oradata/finance/dump/diag/rdbms/finance/finance1/trace/finance1_ora_11821.trc:
    ORA-15080: synchronous I/O operation to a disk failed
    WARNING: failed to write mirror side 2 of virtual extent 0 logical extent 1 of file 256 in group 2 on disk 2 allocation unit 76
    Errors in file /oradump/oradata/finance/dump/diag/rdbms/finance/finance1/trace/finance1_ora_11821.trc:
    ORA-15080: synchronous I/O operation to a disk failed
    WARNING: failed to write mirror side 3 of virtual extent 0 logical extent 2 of file 256 in group 2 on disk 3 allocation unit 78
    Errors in file /oradump/oradata/finance/dump/diag/rdbms/finance/finance1/trace/finance1_ora_11821.trc:
    ORA-00206: error in writing (block 1, # blocks 1) of control file
    ORA-00202: control file: '+CTRL/finance/controlfile/current.256.812371485'
    ORA-15081: failed to submit an I/O operation to a disk
    ORA-15081: failed to submit an I/O operation to a disk
    ORA-221 signalled during: ALTER DATABASE MOUNT...
    trace file:
    Trace file /oradump/oradata/finance/dump/diag/rdbms/finance/finance1/trace/finance1_ora_11821.trc
    Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - 64bit Production
    With the Partitioning, Real Application Clusters, Automatic Storage Management, OLAP,
    Data Mining and Real Application Testing options
    ORACLE_HOME = /rdbms1/app/oracle/product/11.2.0/db_home/
    System name: Linux
    Node name: RAC-NODE1.vod.com
    Release: 2.6.18-128.el5
    Version: #1 SMP Wed Dec 17 11:41:38 EST 2008
    Machine: x86_64
    Instance name: finance1
    Redo thread mounted by this instance: 0 <none>
    Oracle process number: 28
    Unix process pid: 11821, image: [email protected] (TNS V1-V3)
    *** 2013-04-27 00:02:39.859
    *** SESSION ID:(1.3) 2013-04-27 00:02:39.859
    *** CLIENT ID:() 2013-04-27 00:02:39.859
    *** SERVICE NAME:() 2013-04-27 00:02:39.859
    *** MODULE NAME:([email protected] (TNS V1-V3)) 2013-04-27 00:02:39.859
    *** ACTION NAME:() 2013-04-27 00:02:39.859
    ORA-27041: unable to open file
    WARNING: IO Failed. group:2 disk(number.incarnation):1.0xe96d8019 disk_path:/dev/sdd2
    AU:78 disk_offset(bytes):81805312 io_size:16384 operation:Write type:asynchronous
    result:I/O error process_id:11821
    subsys:System iop:0x2b1c84e57250 bufp:0x2b1c84d6ce00 osderr:0x0 osderr1:0x0
    ORA-27041: unable to open file
    WARNING: IO Failed. group:2 disk(number.incarnation):2.0xe96d801a disk_path:/dev/sdd3
    AU:76 disk_offset(bytes):79708160 io_size:16384 operation:Write type:asynchronous
    result:I/O error process_id:11821
    subsys:System iop:0x2b1c84e57128 bufp:0x2b1c84d6ce00 osderr:0x0 osderr1:0x0
    ORA-27041: unable to open file
    WARNING: IO Failed. group:2 disk(number.incarnation):3.0xe96d8018 disk_path:/dev/sdd4
    AU:78 disk_offset(bytes):81805312 io_size:16384 operation:Write type:asynchronous
    result:I/O error process_id:11821
    subsys:System iop:0x2b1c84e57000 bufp:0x2b1c84d6ce00 osderr:0x0 osderr1:0x0
    ORA-15080: synchronous I/O operation to a disk failed
    WARNING: failed to write mirror side 1 of virtual extent 0 logical extent 0 of file 256 in group 2 on disk 1 allocation unit 78
    ORA-15080: synchronous I/O operation to a disk failed
    WARNING: failed to write mirror side 2 of virtual extent 0 logical extent 1 of file 256 in group 2 on disk 2 allocation unit 76
    ORA-15080: synchronous I/O operation to a disk failed
    WARNING: failed to write mirror side 3 of virtual extent 0 logical extent 2 of file 256 in group 2 on disk 3 allocation unit 78
    DDE rules only execution for: ORA 202
    ----- START Event Driven Actions Dump ----
    ---- END Event Driven Actions Dump ----
    ----- START DDE Actions Dump -----
    Executing SYNC actions
    ----- START DDE Action: 'DB_STRUCTURE_INTEGRITY_CHECK' (Async) -----
    Successfully dispatched
    ----- END DDE Action: 'DB_STRUCTURE_INTEGRITY_CHECK' (SUCCESS, 0 csec) -----
    Executing ASYNC actions
    ----- END DDE Actions Dump (total 0 csec) -----
    ORA-00206: error in writing (block 1, # blocks 1) of control file
    ORA-00202: control file: '+CTRL/finance/controlfile/current.256.812371485'
    ORA-15081: failed to submit an I/O operation to a disk
    ORA-15081: failed to submit an I/O operation to a disk
    all the diskgroups are in mount state only
    SQL> select name,state from v$asm_diskgroup;
    NAME STATE
    ARCLOG MOUNTED
    CTRL MOUNTED
    DBFILE MOUNTED
    FRA MOUNTED
    REDO1 MOUNTED
    REDO2 MOUNTED
    VOTE MOUNTED
    since i did not have mirror copy or backup of current control file to replace the correpted one.
    Is there any way to create new control file and transfered to ASM diskgroup and open database. or i need to drop the existing database.
    if i need to drop the db, without open the db how to drop database.
    kindly help on this.
    Thanks in advance.

    Hi,
    Thanks for the replay. im able to open the db.
    But can you tel me how to make my rac db to open with spfile which is on asmdiskgroup.
    SQL> select name,state from v$asm_diskgroup;
    NAME STATE
    ARCLOG MOUNTED
    CTRL MOUNTED
    DBFILE MOUNTED
    FRA MOUNTED
    REDO1 MOUNTED
    REDO2 MOUNTED
    VOTE MOUNTED
    Spfile:
    ASMCMD [+DBFILE/FINANCE/PARAMETERFILE] > pwd
    +DBFILE/FINANCE/PARAMETERFILE
    ASMCMD [+DBFILE/FINANCE/PARAMETERFILE] > ls
    spfile.262.813843989
    i shutdown the db and up the same but it can't take the spfile.
    SQL> show parameter spfile
    NAME TYPE VALUE
    spfile string
    Thanks in advance.

  • Error 5 occurred at Open/Create/Replace File in Write spreadsheet String.vi

    Hi everyone,
    can anyone help me with this problem?
    "error 5 occurred at Open/Create/Replace File in Write spreadsheet String.vi "
    I've been using this part of the program for over a year an suddenly this error occures. But not always, mainly at the very beginning of my tests when the file should not be open.
    Info: I'm using a realtime PXI-System. Maybe the amount of data can cause the problem? (about 2MB)
    Grüße
    Meike
    Attachments:
    writeResults.jpg ‏345 KB
    error5.jpg ‏52 KB

    Hi Meike,
    is the file opened by a different program? Do you try to access it by FTP in parallel to your VI?
    You could use basic file functions instead of WriteSpreadsheetFile. That way you could open the file before starting the loop, keep it open all the time and close it once you're finished - with the added benefit of easier error handling…
    Best regards,
    GerdW
    CLAD, using 2009SP1 + LV2011SP1 + LV2014SP1 on WinXP+Win7+cRIO
    Kudos are welcome

  • How to avoid db file parallel read for nestloop?

    After upgraded to 11gr2, one job took more than twice as long as before on 10g and 11gr1 with compatibility being 10.2.0.
    Same hardware. (See AWR summary below). My analysis points to that Nestloop is doing index range scan for the inner table's index segment,
    and then use db file parallel read to read data from the table segment, and for reasons that I don't know, the parallel read is very slow.
    AVG wait is more than 300ms. How can I fluence optimier to choose db file sequential read to fetch data block from inner table by tweaking
    parameters? Thanks. YD
    Begin Snap: 13126 04-Mar-10 04:00:44 60 3.9
    End Snap: 13127 04-Mar-10 05:00:01 60 2.8
    Elapsed: 59.27 (mins)
    DB Time: 916.63 (mins)
    Report Summary
    Cache Sizes
    Begin End
    Buffer Cache: 4,112M 4,112M Std Block Size: 8K
    Shared Pool Size: 336M 336M Log Buffer: 37,808K
    Load Profile
    Per Second Per Transaction Per Exec Per Call
    DB Time(s): 15.5 13.1 0.01 0.01
    DB CPU(s): 3.8 3.2 0.00 0.00
    Redo size: 153,976.4 130,664.3
    Logical reads: 17,019.5 14,442.7
    Block changes: 848.6 720.1
    Physical reads: 4,149.0 3,520.9
    Physical writes: 16.0 13.6
    User calls: 1,544.7 1,310.9
    Parses: 386.2 327.7
    Hard parses: 0.1 0.1
    W/A MB processed: 1.8 1.5
    Logons: 0.0 0.0
    Executes: 1,110.9 942.7
    Rollbacks: 0.2 0.2
    Transactions: 1.2
    Instance Efficiency Percentages (Target 100%)
    Buffer Nowait %: 99.99 Redo NoWait %: 100.00
    Buffer Hit %: 75.62 In-memory Sort %: 100.00
    Library Hit %: 99.99 Soft Parse %: 99.96
    Execute to Parse %: 65.24 Latch Hit %: 99.95
    Parse CPU to Parse Elapsd %: 91.15 % Non-Parse CPU: 99.10
    Shared Pool Statistics
    Begin End
    Memory Usage %: 75.23 74.94
    % SQL with executions>1: 67.02 67.85
    % Memory for SQL w/exec>1: 71.13 72.64
    Top 5 Timed Foreground Events
    Event Waits Time(s) Avg wait (ms) % DB time Wait Class
    db file parallel read 106,008 34,368 324 62.49 User I/O
    DB CPU 13,558 24.65
    db file sequential read 1,474,891 9,468 6 17.21 User I/O
    log file sync 3,751 22 6 0.04 Commit
    SQL*Net message to client 4,170,572 18 0 0.03 Network

    Its not possible to say anything just by looking at the events.You must understand that statspacks and AWR actualy aggergate the data and than show the results.There may be a very well possibility that some other areas also need to be looked at rather than just focussin on one event.
    You have not mentioned any kind of other info about the wait event like their timings and all that.PLease provide that too.
    And if I understood your question corretly,you said,
    How to avoid these wait events?
    What may be the cause?
    I am afraid that its not possible to discuss each of these wait event here in complete details and also not about what to do when you see them.Please read teh Performance Tuning book which narrates these wait events and corresponding actions.
    Please read and follow this link,
    http://download.oracle.com/docs/cd/B19306_01/server.102/b14211/instance_tune.htm#i18202
    Aman....

  • How to read the data file and write into the same file without a temp table

    Hi,
    I have a requirement as below:
    We are running lockbox process for several business, but for a few businesses we have requirement where in we receive a flat file in different format other than how the transmission format is defined.
    This is a 10.7 to 11.10 migration. In 10.7 the users are using a custom table into which they are first loading the raw data and writing a pl/sql validation on that and loading it into a new flat file and then running the lockbox process.
    But in 11.10 we want to restrict using temp table how can we achieve this.
    Can we read the file first and then do validations accordingly and then write to the same file and process the lockbox.
    Any inputs are highly appreciated.
    Thanks & Regards,
    Lakshmi Kalyan Vara Prasad.

    Hello Gurus,
    Let me tell you about my requirement clearly with an example.
    Problem:
    i am receiving a dat file from bank in below format
    105A371273020563007 07030415509174REF3178503 001367423860020015E129045
    in this detail 1 record starting from 38th character to next 15 characters is merchant reference number
    REF3178503 --- REF denotes it as Sales Order
    ACC denotes it as Customer No
    INV denotes it as Transaction Number
    based on this 15 characters......my validation comes.
    If i see REF i need to pick that complete record and then fill that record with the SO details as per my system and then submit the file for lockbox processing.
    In 10.7 they created a temporary table into which they are loading the data using a control file....once the data is loaded into the temporary table then they are doing a validation and updating the record exactly as required and then creating one another file and then submitting the file for lockbox processing.
    Where as in 11.10 they want to bypass these temporary tables and writing it into a different file.
    Can this be handled by writing a pl/sql procedure ??
    My findings:
    May be i am wrong.......but i think .......if we first get the data into ar_payments_interface_all table and then do the validations and then complete the lockbox process may help.
    Any suggestions from Oracle GURUS is highly appreciated.
    Thanks & Regards,
    Lakshmi Kalyan Vara Prasad.

Maybe you are looking for

  • Error in BPEL console Urgent

    Hi, I try to invoke an OSB project in BPEL process, i deployed it in em console. when i try to test it by giving inputs i am getting the following error, empty variable/expression result. The XPath variable or expression /ns1:GetEmployee_Output/ns3:L

  • XY Graph-Setting Y-Scale visible to False still Shows Corresponding Y scale Max and Min

    Hi Guys, I use XY graph to display the data with 3 Y-scales. When I set any Y scale Visiblity property to False,its still display the Y scale Max and Min range Lines in plot area of the  Graph and making cross line or extra parralel line with other v

  • Can't reduce an image's size

    I have an image that I took in RAW with a Canon 5D. I then masked a large portion of the image using the adjustments brush. The result was what I wanted but the image is now very large. I exported the image to a DNG to retain editability. The resulti

  • Use of XI in MM and SD

    how can we use XI to post Invoice(MM) and orders(SD) in SAP? Edited by: Isabelle Britten on Oct 2, 2008 1:23 PM

  • Getting SOA 10.1.3.5 JmsAdapter to connect to WL jms on other server.

    I have a SOA 10.1.3.5 environment running on windows and I want to create a BPEL project that uses the JmsAdapter to connect to a WL jms queue running on linux box. Following docs I've seen, I copied over the weblogic.jar and wljmsclient.jar to the %