A clarification about block# wait event parameter ....

Hi ,
In Oracle Database Reference of 10g (Part Number B14237-02) about the block# wait event parameter is pointed out ... :
This is the block number of the block for which Oracle needs to wait. The block number is relative to the start of the file. To find the object to which this block belongs, enter the following SQL statements:
select name, kind
from ext_to_obj_view
where file# = file#
     and lowb <= block#
     and highb >= block#;Can you give me a simple example of using the above sql statement.... as ext_to_obj_view object does not exist.....
Many thanks ,
Simon

This view is created by $ORACLE_HOME/rdbms/admin/catclust.sql script (to be run by sys user).
http://download-uk.oracle.com/docs/cd/B19306_01/rac.102/b14197/monitor.htm#RACAD718
Nicolas.

Similar Messages

  • Clarification about OCI_FO_REAUTH failover event of TAF

    Hello everyone,
    Can someone explain my the real meaining of the OCI_FO_REAUTH failover event when we are using TAF?
    All I found is : "OCI_FO_REAUTH indicates that you have multiple authentication handles and failover has occurred after the original authentication. It indicates that a user handle has been re-authenticated. To find out which, the application checks the OCI_ATTR_SESSION attribute of the service context handle (which is the first parameter)."
    But it is not clear for me.
    Regards.
    Carl

    The session receiving this error did not automatically failover, or this automatic failover failed.
    This does not mean however that a new connection would not be possible
    Since you did not mention anything about the system, I can't tell you where to look for the reason.
    If it's a RAC consider looking at the CRS logs.
    This link explains more about the OCI_FO_ABORT : http://www.cs.umbc.edu/portal/help/oracle8/server.815/a67846/new_adva.htm
    Success!
    FJFranken

  • Need clarification about block in Sale order

    we would like to know is there any other standard t-code available to do the sales order block removal which we are doing through VA02. blocks like schedule line block, road permit block. Thescenario is as follows:
    Line Item Vise :
    Z1 Block - If the Customer Doenst want the material / Order waiting for Statutory Document / PO issue / Off Spec  ,Z1 Block on the line Item level is used  inorder to stop MO during Order Loading
    Z3 Block - If an order has more than one line items and Business / Customer needs only 1 Item to be fulfilled and remg items to be fulfilled at the later stage or material has to be diverted to  Other orders Z3 block is used during scheduling subject to Business Approvals.
    Header Vise :
    Z1 Block - Customer cancellation happens post order loading and post mfg  ,Z1 block is used in Header Level - done during Post Order Loading Subject to business  Approvals.
    Z3 Block - If the Demand is More than the supply and Business / Customer Needs critical order delivery to happen for specific Orders,Z3 block is used in order make the FG free and allocate specific Orders subject to Business Approvals.
    Partial Delivery of a PO on Allocation:
    Business requires Material for T Models to go on Allocation .Suppose 2 MTMs are loaded in the same SO but business needs only one MTM to be billed and hold Other MTM Delivery Grouping is changed in the SO and qty has to be broken in accordance with the allocation
    Partial Delivery of a PO on Relation:
    If Supply is not there for the Entire PO and still Customer requires Partial Qty whatever it has then the same will made Partillay after getting customer concurrence
    what is the standard t code availabel in the sceanrio

    Hi,
    You can try TCode V.00
    This transaction when executed will give you the list of all the sales documents blocked for delivery per sales organization. There are various other criteria which might be useful. This transaction will allow you to edit each sales document.
    If this is not the one that you want, then perhaps you might have to develop one.
    Thanks
    Mukund S

  • (  name-service call wait   ) event   is amoung the top 5 wait events

    10.2.0.3 2node- RAC
    When I check the wait event in the active session wait event the sessions can be see that they are blocked by the LMON process. The wait event appears only on one node.
    It is very hard to find information on the net or on the metalink.
    How could I overcome this wait event ?
    select program, type from v$session
         where sid in
         (select blocking_session from v$active_session_history
                   where event like 'name-service%'
         and rownum < 1000 )
    oracle@dbokyanus1 (LMON) , BACKGROUND
    Top 5 Timed Events Avg %Total
    ~~~~~~~~~~~~~~~~~~ wait Call
    Event Waits Time (s) (ms) Time
    db file sequential read 4,331,507 15,218 *4* *31.2*
    CPU time *8* *17.5*
    log file sync 1,462,968 5,513 *4* *11.3*
    name-service call wait 72,058 4,545 *63* *9.3*
    SQL*Net message from dblink 4,197 4,047 *964* *8.3*

    oceanic-815 wrote:
    10.2.0.3 2node- RAC
    When I check the wait event in the active session wait event the sessions can be see that they are blocked by the LMON process. The wait event appears only on one node.
    It is very hard to find information on the net or on the metalink.
    If I use Google to find information about this
    I ran into this page.
    There is indeed not much to find about this wait-event, other than there is probably some sort of network communication problem between the two nodes.
    Maybe the best solution is to raise a S/R at Oracle support

  • CPU wait events on ADDM report

    Hello,
    My Oracle version is:
    Connected to Oracle Database 11g Enterprise Edition Release 11.1.0.7.0 Yesterday I was taking a look on an ADDM report and spot the following:
       Rationale
          SQL statement with SQL_ID "0mgk8gx9hj71d" was executed 777 times and had
          an average elapsed time of 42 seconds.
       Rationale
          Waiting for event "resmgr:cpu quantum" in wait class "Scheduler"
          accounted for 34% of the database time spent in processing the SQL
          statement with SQL_ID "0mgk8gx9hj71d".After that, I started looking for how ADDM could know that the SQL_ID "0mgk8gx9hj71d" waited 34% on "resmgr:cpu quantum" event. No lucky with that...
    The only wait event information related to a given SQL_ID I've found on v$active_session_history (or the AWR persisted table for it), but in the ASH there is no information about CPU wait events like "cpu quantum". When the session is waiting for CPU, there is no event related in v$ash.
    So, my question is: where ADDM got the information that the SQL waited 34% of the time on "resmgr:cpu quantum"?
    Thanks,
    Heitor Kirsten

    Hi,
    Is a session waiting for CPU resources ("res:cpu quantum") considered as an active session ? Maybe not.
    I guess (I made no test) that this maybe the reason why this kind of wait is not shown in the active session history .
    Regards
    Maurice

  • Wait event enq: JD - contention

    Hi All,
    In the top-5 wait events of the AWR-report i encounter a enq: JD contention wait event (wait class Other).
    I only figured out that JD means Job Queue Date.
    Can anybody tell me more about this wait event?
    Thanks in advance,
    Jeroen van Schaijk

    Hi All,
    I have additional information:
    This wait event synchronizes dates between job queue coordinator and slave processes.
    It appears that this wait event takes more than 10% of the total wait time!
    Does anybody know how to deal with this wait event?
    Thanks in advance,
    Jeroen van Schaijk

  • About single-task message wait event

    Hello
    I have several active users, some of them from 2 an 3 days ago with single-task message wait event and their last_call was many time ago. One of users, blocked to other users just a little while ago and Concurrency grow up to 20 % and was on increase. i had to kill this user and all were well, concurrency dessapeared.
    How could I avoid this behavior??
    How could I kill these type of user by automatic way??
    Thanks

    Hi,
    according to me active user is different
    according to me active user is session or oracle process is doing something else like dml or ddl execution or select stmt else session is idel.
    trace the session what is doing? is may be problem with dead connection
    use oradebug and set the 10046 at level 12 and format it with tkprof utility.
    paste it thread
    Kind Regards,
    Rakesh jayappa

  • About wait events of awr

    is there anyone who can helip to advise me the meaning of
    1.SQL*Net break/reset to client
    2. Streams AQ: waiting for messages in the queue
    3. wait for unread message on broadcast channel
    we are processing a performence test , tks for your kind advise

    You can ignore these events as they are IDLE events, not WAIT events. In short, they mean user is connected but is not doing anything.

  • Problem identifying db object for "buffer busy waits" event.

    10.2.0.3
    AIX 64
    SELECT username, a.p1text, a.p1, a.p2text, a.p2, a.p3text, a.p3, event FROM v$session a WHERE
    a.status='ACTIVE'
    AND a.event = 'buffer busy waits'
    Query reports about 40 active sessions with this information:
    file# 3746
    block# 2
    class# 13
    select
    owner,
    segment_name,
    segment_type
    from
    dba_extents
    where
    file_id = 3746
    and
    2 between block_id and block_id + blocks -1;
    no rows returned
    SELECT MAX(a.file#) FROM sys.file$ a
    3535
    This was only a temporary situation when after couple of minutes(7) wait event "buffer busy waits" dissapeared completely.
    Any ideas?
    Thank you,
    Daniel.

    http://perfvision.com/papers/06_buffer_cache.ppt
    Slide 80-81 points at increasing the size of the initial and next extent for File Header Block buffer busy waits
    Side 85 points at high extent allocation for File Header Block buffer busy waits
    http://perfvision.com/ftp/hotsos/aas.ppt
    Side 55 points at extent allocation too small/too many extents being allocated for File Header Block buffer busy waits
    A couple hints from the documentation:
    http://download.oracle.com/docs/cd/B19306_01/server.102/b14211/instance_tune.htm
    "To determine the possible causes [of buffer busy waits], first query V$SESSION to identify the value of ROW_WAIT_OBJ# when the session waits for buffer busy waits."
    "To identify the object and object type contended for, query DBA_OBJECTS using the value for ROW_WAIT_OBJ# that is returned from V$SESSION."
    "V$SEGMENT_STATISTICS - This is a user-friendly view of statistic values. In addition to all the columns of V$SEGSTAT, it has information about such things as the segment owner and table space name. It makes the statistics easy to understand, but it is more costly."
    You may want to query DBA_TEMP_FILES for the specific FILE_ID identified by the V$SESSION. Taking a look at V$SEGMENT_STATISTICS might also be helpful.
    Are you using dictionary managed tablespaces, locally managed tablespaces with manual extent size management, ASSM with manual extent size management, or ASSM with automatic extent size management?
    Charles Hooper
    IT Manager/Oracle DBA
    K&M Machine-Fabricating, Inc.

  • 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                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                           

  • Wait events

    Hi ! I have the following wait events in my top timed and I don't know who originated them:
    Wait Event Wait Time Summary Avg Wait Time (ms)
    I# Class Event Waits %Timeouts Total(s) Avg(ms) %DB time Avg Min Max Std Dev Cnt
    * DB CPU N/A N/A 59,651.48 N/A 45.87 2
    User I/O db file sequential read 4,369,213 0.0 20,831.46 4.8 16.02 4.72 4.29 5.14 0.60 2
    Other enq: CF - contention 155,822 3.9 10,390.74 66.7 7.99 68.62 60.31 76.94 11.76 2
    System I/O RMAN backup & recovery I/O 87,205 0.0 5,477.09 62.8 9.15 62.81 62.81 62.81 1
    Cluster gc current block 2-way 2,914,457 0.0 4,811.61 1.7 3.70 1.67 1.60 1.74 0.10 2
    System I/O control file sequential read 3,038,672 0.0 3,762.66 1.2 2.89 1.24 1.22 1.27 0.04 2
    Concurrenc os thread startup 2,842 0.0 3,695.14 1300.2 2.84 1311.83 1143.07 1480.59 238.66 2
    System I/O log file parallel write 1,341,907 0.0 2,530.17 1.9 1.95 1.88 1.88 1.89 0.01 2
    Other reliable message 471,495 0.1 2,388.01 5.1 1.84 5.08 4.12 6.03 1.35 2
    Concurrenc row cache lock 3,135,774 0.0 2,224.53 0.7 1.71 0.72 0.68 0.75 0.05 2
    1 DB CPU N/A N/A 22,584.30 N/A 37.75
    User I/O db file sequential read 2,451,215 0.0
    System I/O RMAN backup & recovery I/O 87,205 0.0
    Other enq: CF - contention 59,735 5.3
    Cluster gc current block 2-way 1,803,542 0.0
    System I/O control file sequential read 1,831,180 0.0
    Concurrenc os thread startup 1,323 0.0
    System I/O log file parallel write 727,883 0.0
    Cluster gc cr multi block request 523,744 0.0
    Concurrenc row cache lock 1,830,913 0.0
    2 DB CPU N/A N/A
    User I/O db file sequential read 1,917,998 0.0
    Other enq: CF - contention 96,087 3.0
    Cluster gc current block 2-way 1,110,915 0.0
    Concurrenc os thread startup 1,519 0.0
    System I/O control file sequential read 1,207,492 0.0
    User I/O direct path read 404,587 0.0
    Other reliable message 233,033 0.1
    System I/O log file parallel write 614,024 0.0
    System I/O control file parallel write 128,905 0.0
    Those are the most worrying events:
    enq: CF - contention
    I/O control file sequential read
    Concurrenc os thread startup
    I have been investigating and I wonder what is wrong to get Concurrenc os thread startup. According to one blog, os thread should be always related with network issues...
    The awr snapshot is from my production window day.
    Rac 11.2.0.3 two nodes on Solaris Sparc 10.

    I have studied the ASH in the problematic period and I have found that there are some full scans:
    Summary of All User Input
    Format         : TEXT
    DB Id          : 2752323407
    Inst num       : 1
    Begin time     : 08-Feb-13 09:30:00
    End time       : 08-Feb-13 10:20:00
    Slot width     : Default
    Report targets : 0
    Report name    : ashrpt_1_0208_1020.txt
    ASH Report For dbp/dbp1
    DB Name         DB Id    Instance     Inst Num Release     RAC Host
    dbp           2752323407 dbp1                1 11.2.0.3.0  YES host-dbp-1
    CPUs           SGA Size       Buffer Cache        Shared Pool    ASH Buffer Size
      16     12,651M (100%)    10,048M (79.4%)     1,921M (15.2%)       32.0M (0.3%)
              Analysis Begin Time:   08-Feb-13 09:30:00
                Analysis End Time:   08-Feb-13 10:20:00
                     Elapsed Time:        50.0 (mins)
                Begin Data Source:   DBA_HIST_ACTIVE_SESS_HISTORY
                                     in AWR snapshot 5100
                  End Data Source:   DBA_HIST_ACTIVE_SESS_HISTORY
                                     in AWR snapshot 5101
                                      + V$ACTIVE_SESSION_HISTORY
                     Sample Count:      10,069
          Average Active Sessions:       33.56
      Avg. Active Session per CPU:        2.10
                    Report Target:   None specified
    Top User Events                     DB/Inst: dbp/dbp1  (Feb 08 09:30 to 10:20)
                                                                   Avg Active
    Event                               Event Class        % Event   Sessions
    library cache lock                  Concurrency          43.73      14.68
    cursor: pin S wait on X             Concurrency          18.61       6.25
    CPU + Wait for CPU                  CPU                  15.77       5.29
    reliable message                    Other                 5.88       1.97
    enq: KO - fast object checkpoint    Application           3.48       1.17
    Top Background Events               DB/Inst: dbp/dbp1  (Feb 08 09:30 to 10:20)
                                                                   Avg Active
    Event                               Event Class     % Activity   Sessions
    CPU + Wait for CPU                  CPU                   1.25       0.42
    Top Cluster Events                  DB/Inst: dbp/dbp1  (Feb 08 09:30 to 10:20)
    Event                          % Event Remote I % Activity
    gc current block 2-way            1.72        2       1.72
    gc cr grant 2-way                 1.58      N/A       1.07
    Top Event P1/P2/P3 Values           DB/Inst: dbp/dbp1  (Feb 08 09:30 to 10:20)
    Event                          % Event  P1 Value, P2 Value, P3 Value % Activity
    Parameter 1                Parameter 2                Parameter 3
    library cache lock               43.75 "29115227816","29218763456","       1.22
    handle address             lock address               100*mode+namespace
                                           "29115227816","28694732944","       1.20
                                           "29115227816","28812373936","       1.17
    cursor: pin S wait on X          18.61 "1497800770","3934190043136",       1.54
    idn                        value                      where
                                           "1497800770","7773890805760",       1.15
    reliable message                  6.07 "30432532808","30354909248","       0.13
    channel context            channel handle             broadcast message
    enq: KO - fast object checkpoi    3.49      "1263468550","65640","1"       0.52
    name|mode                  2                          0
    db file sequential read           1.81               "1","25220","1"       0.01
    file#                      block#                     blocks
    Top Service/Module                  DB/Inst: dbp/dbp1  (Feb 08 09:30 to 10:20)
    Service        Module                   % Activity Action               % Action
    dbp_DVEBMGS11  CL_SQL_STATEMENT========      86.80 383                     86.80
    dbp_D10_0066   CL_SQL_STATEMENT========       6.28 383                      3.34
                                                       104                      2.94
    dbp_D10_0064   CL_SQL_STATEMENT========       2.40 383                      2.39
    SYS$BACKGROUND UNNAMED                        1.51 UNNAMED                  1.51
    Top Client IDs                      DB/Inst: dbp/dbp1  (Feb 08 09:30 to 10:20)
                      No data exists for this section of the report.
    Top SQL Command Types               DB/Inst: dbp/dbp1  (Feb 08 09:30 to 10:20)
    -> 'Distinct SQLIDs' is the count of the distinct number of SQLIDs
          with the given SQL Command Type found over all the ASH samples
          in the analysis period
                                               Distinct            Avg Active
    SQL Command Type                             SQLIDs % Activity   Sessions
    SELECT                                          485      94.56      31.74
    ALTER TABLE                                     220       2.89       0.97
    Top Phases of Execution             DB/Inst: dbp/dbp1  (Feb 08 09:30 to 10:20)
                                              Avg Active
    Phase of Execution             % Activity   Sessions
    Parse                               67.50      22.66
    SQL Execution                       30.46      10.22
    Hard Parse                           5.37       1.80
    Top Remote Instances                DB/Inst: dbp/dbp1  (Feb 08 09:30 to 10:20)
    Wait Class           % Wait  Remote I % Activity
    Cluster                 5.22        2       3.90
                                      N/A       1.27
    Top SQL with Top Events     DB/Inst: dbp/dbp1  (Feb 08 09:30 to 10:20)
                                                            Sampled #
                     SQL ID             Planhash        of Executions     % Activity
    Event                          % Event Top Row Source                    % RwSrc
              350v06jcnd822                  N/A                    0          18.03
    library cache lock                9.41 ** Row Source Not Available **       9.41
    SELECT "DT"."SID_0CALMONTH" AS "S____048" ,"D3"."SID_0MATERIAL" AS "S____006" ,
    "DU"."SID_0UNIT" AS "S____023" ,"DT"."SID_0CALDAY" AS "S____021" ,"D2"."SID_0MET
    YPE" AS "S____1342" ,"D2"."SID_0VTYPE" AS "S____504" ,"X33"."S__Z99GRMAT" AS "S_
    ___4443" , SUM ( "F"."QUANTITY" ) AS "Z____1299" , COUNT( * ) AS "Z____016"
                                             N/A                    0          18.03
    cursor: pin S wait on X           8.62 ** Row Source Not Available **       8.62
    SELECT "DT"."SID_0CALMONTH" AS "S____048" ,"D3"."SID_0MATERIAL" AS "S____006" ,
    "DU"."SID_0UNIT" AS "S____023" ,"DT"."SID_0CALDAY" AS "S____021" ,"D2"."SID_0MET
    YPE" AS "S____1342" ,"D2"."SID_0VTYPE" AS "S____504" ,"X33"."S__Z99GRMAT" AS "S_
    ___4443" , SUM ( "F"."QUANTITY" ) AS "Z____1299" , COUNT( * ) AS "Z____016"
              48unmtd983uz6                  N/A                    0          16.75
    library cache lock               12.87 ** Row Source Not Available **      12.87
    SELECT "DT"."SID_0CALDAY" AS "S____021" ,"DT"."SID_0CALMONTH" AS "S____048" ,"D
    3"."SID_0MATERIAL" AS "S____006" ,"DU"."SID_0UNIT" AS "S____023" ,"D2"."SID_0MET
    YPE" AS "S____1342" ,"D2"."SID_0VTYPE" AS "S____504" , SUM ( "F"."QUANTITY" )
    AS "Z____1299" , COUNT( * ) AS "Z____016" FROM "/BIC/FZ99IC114" "F" JOIN "/BIC
                                             N/A                    0          16.75
    cursor: pin S wait on X           3.88 ** Row Source Not Available **       3.88
    SELECT "DT"."SID_0CALDAY" AS "S____021" ,"DT"."SID_0CALMONTH" AS "S____048" ,"D
    3"."SID_0MATERIAL" AS "S____006" ,"DU"."SID_0UNIT" AS "S____023" ,"D2"."SID_0MET
    YPE" AS "S____1342" ,"D2"."SID_0VTYPE" AS "S____504" , SUM ( "F"."QUANTITY" )
    AS "Z____1299" , COUNT( * ) AS "Z____016" FROM "/BIC/FZ99IC114" "F" JOIN "/BIC
              350v06jcnd822           2426825131                    0          15.49
    library cache lock                9.74 ** Row Source Not Available **       9.74
    SELECT "DT"."SID_0CALMONTH" AS "S____048" ,"D3"."SID_0MATERIAL" AS "S____006" ,
    "DU"."SID_0UNIT" AS "S____023" ,"DT"."SID_0CALDAY" AS "S____021" ,"D2"."SID_0MET
    YPE" AS "S____1342" ,"D2"."SID_0VTYPE" AS "S____504" ,"X33"."S__Z99GRMAT" AS "S_
    ___4443" , SUM ( "F"."QUANTITY" ) AS "Z____1299" , COUNT( * ) AS "Z____016"
    cursor: pin S wait on X           4.14 ** Row Source Not Available **       4.14
    CPU + Wait for CPU                1.61 SELECT STATEMENT                     1.58
              48unmtd983uz6           3511339786                    0          14.98
    library cache lock               11.50 ** Row Source Not Available **      11.50
    SELECT "DT"."SID_0CALDAY" AS "S____021" ,"DT"."SID_0CALMONTH" AS "S____048" ,"D
    3"."SID_0MATERIAL" AS "S____006" ,"DU"."SID_0UNIT" AS "S____023" ,"D2"."SID_0MET
    YPE" AS "S____1342" ,"D2"."SID_0VTYPE" AS "S____504" , SUM ( "F"."QUANTITY" )
    AS "Z____1299" , COUNT( * ) AS "Z____016" FROM "/BIC/FZ99IC114" "F" JOIN "/BIC
    cursor: pin S wait on X           1.97 ** Row Source Not Available **       1.97
    CPU + Wait for CPU                1.51 SELECT STATEMENT                     1.42
              07tcvyb6frtkx           2929764020                    1           1.87
    gc cr grant 2-way                 0.80 TABLE ACCESS - BY USER ROWID         0.75
    SELECT "D3"."SID_0SHIP_TO" AS "SID" FROM "/BIC/FZ99IC035" "F" JOIN "/BIC/DZ99IC
    0352" "D2" ON "F" . "KEY_Z99IC0352" = "D2" . "DIMID" JOIN "/BI0/XMATERIAL" "X9"
    ON "D2" . "SID_0MATERIAL" = "X9" . "SID" JOIN "/BIC/DZ99IC0355" "D5" ON "F" .
    "KEY_Z99IC0355" = "D5" . "DIMID" JOIN "/BIC/DZ99IC0353" "D3" ON "F" . "KEY_Z99
    Top SQL with Top Events     DB/Inst: dbp/dbp1  (Feb 08 09:30 to 10:20)
                                                            Sampled #
                     SQL ID             Planhash        of Executions     % Activity
    Event                          % Event Top Row Source                    % RwSrc
    Top SQL with Top Row Sources        DB/Inst: dbp/dbp1  (Feb 08 09:30 to 10:20)
                                                            Sampled #
                     SQL ID             PlanHash        of Executions     % Activity
    Row Source                               % RwSrc Top Event               % Event
              350v06jcnd822                  N/A                    0          18.03
    ** Row Source Not Available **             18.03 library cache lock         9.41
    SELECT "DT"."SID_0CALMONTH" AS "S____048" ,"D3"."SID_0MATERIAL" AS "S____006" ,
    "DU"."SID_0UNIT" AS "S____023" ,"DT"."SID_0CALDAY" AS "S____021" ,"D2"."SID_0MET
    YPE" AS "S____1342" ,"D2"."SID_0VTYPE" AS "S____504" ,"X33"."S__Z99GRMAT" AS "S_
    ___4443" , SUM ( "F"."QUANTITY" ) AS "Z____1299" , COUNT( * ) AS "Z____016"
              48unmtd983uz6                  N/A                    0          16.75
    ** Row Source Not Available **             16.75 library cache lock        12.87
    SELECT "DT"."SID_0CALDAY" AS "S____021" ,"DT"."SID_0CALMONTH" AS "S____048" ,"D
    3"."SID_0MATERIAL" AS "S____006" ,"DU"."SID_0UNIT" AS "S____023" ,"D2"."SID_0MET
    YPE" AS "S____1342" ,"D2"."SID_0VTYPE" AS "S____504" , SUM ( "F"."QUANTITY" )
    AS "Z____1299" , COUNT( * ) AS "Z____016" FROM "/BIC/FZ99IC114" "F" JOIN "/BIC
              350v06jcnd822           2426825131                    0          15.49
    ** Row Source Not Available **             13.91 library cache lock         9.74
    SELECT "DT"."SID_0CALMONTH" AS "S____048" ,"D3"."SID_0MATERIAL" AS "S____006" ,
    "DU"."SID_0UNIT" AS "S____023" ,"DT"."SID_0CALDAY" AS "S____021" ,"D2"."SID_0MET
    YPE" AS "S____1342" ,"D2"."SID_0VTYPE" AS "S____504" ,"X33"."S__Z99GRMAT" AS "S_
    ___4443" , SUM ( "F"."QUANTITY" ) AS "Z____1299" , COUNT( * ) AS "Z____016"
    SELECT STATEMENT                            1.58 CPU + Wait for CPU         1.58
              48unmtd983uz6           3511339786                    0          14.98
    ** Row Source Not Available **             13.56 library cache lock        11.50
    SELECT "DT"."SID_0CALDAY" AS "S____021" ,"DT"."SID_0CALMONTH" AS "S____048" ,"D
    3"."SID_0MATERIAL" AS "S____006" ,"DU"."SID_0UNIT" AS "S____023" ,"D2"."SID_0MET
    YPE" AS "S____1342" ,"D2"."SID_0VTYPE" AS "S____504" , SUM ( "F"."QUANTITY" )
    AS "Z____1299" , COUNT( * ) AS "Z____016" FROM "/BIC/FZ99IC114" "F" JOIN "/BIC
    SELECT STATEMENT                            1.42 CPU + Wait for CPU         1.42
              07tcvyb6frtkx           2929764020                    1           1.87
    TABLE ACCESS - BY USER ROWID                1.59 gc cr grant 2-way          0.75
    SELECT "D3"."SID_0SHIP_TO" AS "SID" FROM "/BIC/FZ99IC035" "F" JOIN "/BIC/DZ99IC
    0352" "D2" ON "F" . "KEY_Z99IC0352" = "D2" . "DIMID" JOIN "/BI0/XMATERIAL" "X9"
    ON "D2" . "SID_0MATERIAL" = "X9" . "SID" JOIN "/BIC/DZ99IC0355" "D5" ON "F" .
    "KEY_Z99IC0355" = "D5" . "DIMID" JOIN "/BIC/DZ99IC0353" "D3" ON "F" . "KEY_Z99
    Top SQL using literals              DB/Inst: dbp/dbp1  (Feb 08 09:30 to 10:20)
    -> FORCE_MATCHING_SIGNATURE is used to identify SQL statements that are
          identical except for their use of literals.
    -> Please refer to the Oracle Database Reference to understand how
          the FORCE_MATCHING_SIGNATURE is derived.
                                         # of Sampled
    FORCE_MATCHING_SIGNATURE % Activity SQL Versions
    Example SQL 1
    Example SQL 2
          1021017294885722791       2.89          218
    0htvt0stu1vtq
    SELECT COUNT(*) FROM "/BIC/FZ99IC003" WHERE "KEY_Z99IC003P" = :A0
    0htvt0stu1vtq
    Top Parsing Module/Action           DB/Inst: dbp/dbp1  (Feb 08 09:30 to 10:20)
    Module                         Action                           % Activ Event
    CL_SQL_STATEMENT============== 383                                67.25 library
                                   383                                      cursor:
                                   383                                      CPU + Wa
    Top Sessions running PQs            DB/Inst: dbp/dbp1  (Feb 08 09:30 to 10:20)
    -> This section aggregates all the work done by the PQ slaves into
          the session issuing the parallel query.
    Sid,Srl# (Inst) % Activity SQL ID        Event                          % Event
    User                 Program
      1506,   19(1)      33.57 350v06jcnd822 library cache lock               19.15
    UserID:
    SELECT "DT"."SID_0CALMONTH" AS "S____048" ,"D3"."SID_0MATERIAL" AS "S____006" ,
    "DU"."SID_0UNIT" AS "S____023" ,"DT"."SID_0CALDAY" AS "S____021" ,"D2"."SID_0MET
    YPE" AS "S____1342" ,"D2"."SID_0VTYPE" AS "S____504" ,"X33"."S__Z99GRMAT" AS "S_
    ___4443" , SUM ( "F"."QUANTITY" ) AS "Z____1299" , COUNT( * ) AS "Z____016"
                                             cursor: pin S wait on X          12.76
    SELECT "DT"."SID_0CALMONTH" AS "S____048" ,"D3"."SID_0MATERIAL" AS "S____006" ,
    "DU"."SID_0UNIT" AS "S____023" ,"DT"."SID_0CALDAY" AS "S____021" ,"D2"."SID_0MET
    YPE" AS "S____1342" ,"D2"."SID_0VTYPE" AS "S____504" ,"X33"."S__Z99GRMAT" AS "S_
    ___4443" , SUM ( "F"."QUANTITY" ) AS "Z____1299" , COUNT( * ) AS "Z____016"
                                             CPU + Wait for CPU                1.61
    SELECT "DT"."SID_0CALMONTH" AS "S____048" ,"D3"."SID_0MATERIAL" AS "S____006" ,
    "DU"."SID_0UNIT" AS "S____023" ,"DT"."SID_0CALDAY" AS "S____021" ,"D2"."SID_0MET
    YPE" AS "S____1342" ,"D2"."SID_0VTYPE" AS "S____504" ,"X33"."S__Z99GRMAT" AS "S_
    ___4443" , SUM ( "F"."QUANTITY" ) AS "Z____1299" , COUNT( * ) AS "Z____016"
      2255, 1067(1)      31.78 48unmtd983uz6 library cache lock               24.37
    UserID:
    SELECT "DT"."SID_0CALDAY" AS "S____021" ,"DT"."SID_0CALMONTH" AS "S____048" ,"D
    3"."SID_0MATERIAL" AS "S____006" ,"DU"."SID_0UNIT" AS "S____023" ,"D2"."SID_0MET
    YPE" AS "S____1342" ,"D2"."SID_0VTYPE" AS "S____504" , SUM ( "F"."QUANTITY" )
    AS "Z____1299" , COUNT( * ) AS "Z____016" FROM "/BIC/FZ99IC114" "F" JOIN "/BIC
                                             cursor: pin S wait on X           5.85
    SELECT "DT"."SID_0CALDAY" AS "S____021" ,"DT"."SID_0CALMONTH" AS "S____048" ,"D
    3"."SID_0MATERIAL" AS "S____006" ,"DU"."SID_0UNIT" AS "S____023" ,"D2"."SID_0MET
    YPE" AS "S____1342" ,"D2"."SID_0VTYPE" AS "S____504" , SUM ( "F"."QUANTITY" )
    AS "Z____1299" , COUNT( * ) AS "Z____016" FROM "/BIC/FZ99IC114" "F" JOIN "/BIC
                                             CPU + Wait for CPU                1.51
    SELECT "DT"."SID_0CALDAY" AS "S____021" ,"DT"."SID_0CALMONTH" AS "S____048" ,"D
    3"."SID_0MATERIAL" AS "S____006" ,"DU"."SID_0UNIT" AS "S____023" ,"D2"."SID_0MET
    YPE" AS "S____1342" ,"D2"."SID_0VTYPE" AS "S____504" , SUM ( "F"."QUANTITY" )
    AS "Z____1299" , COUNT( * ) AS "Z____016" FROM "/BIC/FZ99IC114" "F" JOIN "/BIC
    Top DB Objects                      DB/Inst: dbp/dbp1  (Feb 08 09:30 to 10:20)
    -> With respect to Application, Cluster, User I/O and buffer busy waits only.
          Object ID % Activity Event                             % Event
    Object Name (Type)                                    Tablespace
           13661539       2.45 gc buffer busy acquire               0.87
    SAPSR3./BIC/EZ99IC013 (TABLE)                         PSAPSR3SSD
    Top DB Files                        DB/Inst: dbp/dbp1  (Feb 08 09:30 to 10:20)
    -> With respect to Cluster and User I/O events only.
            File ID % Activity Event                             % Event
    File Name                                             Tablespace
                 53       3.60 gc current block 2-way               0.98
    +dbp_DATA/dbp_2/datafile/psapsr3ssd.315.805562113     PSAPSR3SSD
    Top Latches                         DB/Inst: dbp/dbp1  (Feb 08 09:30 to 10:20)
                      No data exists for this section of the report.
    Activity Over Time                  DB/Inst: dbp/dbp1  (Feb 08 09:30 to 10:20)
    -> Analysis period is divided into smaller time slots
    -> Top 3 events are reported in each of those slots
    -> 'Slot Count' shows the number of ASH samples in that slot
    -> 'Event Count' shows the number of ASH samples waiting for
       that event in that slot
    -> '% Event' is 'Event Count' over all ASH samples in the analysis period
                             Slot                                   Event
    Slot Time (Duration)    Count Event                             Count % Event
    09:30:00   (5.0 min)      260 gc buffer busy acquire               43    0.43
                                  reliable message                     34    0.34
                                  CPU + Wait for CPU                   29    0.29
    09:35:00   (5.0 min)      303 CPU + Wait for CPU                   76    0.75
                                  db file sequential read              40    0.40
                                  gc buffer busy acquire               39    0.39
    09:40:00   (5.0 min)      366 CPU + Wait for CPU                  209    2.08
                                  db file sequential read              26    0.26
                                  gc current block 2-way               22    0.22
    09:45:00   (5.0 min)      511 CPU + Wait for CPU                  249    2.47
                                  cursor: pin S wait on X              93    0.92
                                  reliable message                     45    0.45
    09:50:00   (5.0 min)    2,245 cursor: pin S wait on X           1,442   14.32
                                  library cache lock                  407    4.04
                                  reliable message                    112    1.11
    09:55:00   (5.0 min)    2,037 library cache lock                1,378   13.69
                                  cursor: pin S wait on X             297    2.95
                                  CPU + Wait for CPU                  125    1.24
    10:00:00   (5.0 min)    1,823 library cache lock                1,371   13.62
                                  CPU + Wait for CPU                  263    2.61
                                  reliable message                     72    0.72
    10:05:00   (5.0 min)    1,273 library cache lock                  866    8.60
                                  CPU + Wait for CPU                  155    1.54
                                  reliable message                     96    0.95
    10:10:00   (5.0 min)      798 library cache lock                  350    3.48
                                  CPU + Wait for CPU                  287    2.85
                                  reliable message                     54    0.54
    10:15:00   (5.0 min)      436 CPU + Wait for CPU                  200    1.99
                                  reliable message                     61    0.61
                                  enq: KO - fast object checkpoi       42    0.42
              -------------------------------------------------------------Problems are always on instance 1.
    The queries are different each day, the top sql with performance problem changes the sql_id and I cant attack them or apply a sql profile or tune them because they only execute during a period.
    Any idea?
    :(

  • What's wrong from this wait event

    Please,
    Below are two tables showing respectively database wait event by wait class and session wait event by wait class.
    1. Database wait event by wait class
    WAIT TOTAL PCT TIME PCT
    CLASS WAITS WAITS WAITED_SECS TIME
    Application 7427 .08 1572.45 76.29
    User I/O 50416 .57 193.24 9.38
    Network 8714874 98.66 177.67 8.62
    System I/O 48169 .55 85.98 4.17
    2. Session wait event by wait class
    SID USER WAIT TOTAL TIME_
    NAME CLASS WAITS WAITED_SECS
    318 PMS1000 Application 110 321.64
    259 PMS1000 Application 81 212.8
    318 PMS1000 Network 541943 31.8
    259 PMS1000 Network 258368 17.76
    258 PMS1000 Network 132774 9.34
    318 PMS1000 User I/O 1392 7.49
    Top Events found:
    CPU + WAIT for CPU
    ROW lock contention
    SQL*Net more data from/to client
    Question:
    What may cause the application wait_class to be at the top?, event though the row lock contention was found ?
    I also think the system may sufering from a network bottleneck, I also thinking to set SDU parameter, but the network is 1Gb speed, and I don't know if this can help.
    Does someone give me some clue to pinpoint what is going wrong wiht the above stats?
    thanks enough

    user552326
    I've used the "code" tags to make your first section of data more readable:
    WAIT               TOTAL       PCT        TIME             PCT
    CLASS              WAITS       WAITS      WAITED_SECS      TIME
    Application              7427        .08           1572.45      76.29
    User I/O                50416        .57            193.24       9.38
    Network               8714874      98.66            177.67       8.62
    System I/O              48169        .55             85.98       4.17 If you want to know what events belong to each wait class you can query v$event_name:
    select wait_class, name
    from v$event_name
    order by wait_class, nameThe events in class "Application" are:
    SQL*Net break/reset to client
    SQL*Net break/reset to dblink
    Streams capture: filter callback waiting for ruleset
    Streams: apply reader waiting for DDL to apply
    Wait for Table Lock
    enq: KO - fast object checkpoint
    enq: PW - flush prewarm buffers
    enq: RO - contention
    enq: RO - fast object reuse
    enq: TM - contention
    enq: TX - row lock contention
    enq: UL - contention
    As you can see, this is consistent with your comment about the top event being "row lock contention". The implication of the name given to this wait class is that it is your application design that is causing the problem. Your biggest problem is that your code allows your users to lock each other out.
    Looking at the summary numbers, the time spent on waiting for other users to get out of the way is a very large fraction of your total wait - until you deal with that, problems relating to I/O and network appear to be pretty irrelevant. Having said that, you seem to do a very large number of round-trips on the network - so maybe the amount of time you are losing is not hugely significant compared to the amount of work you are getting done. (You didn't actually tell us how long it took or how many concurrent users, to accumulate this wait time).
    Regards
    Jonathan Lewis
    http://jonathanlewis.wordpress.com
    http://www.jlcomp.demon.co.uk

  • What do the wait events 'gc cr failure' and 'cr request retry' mean?

    I'm trying to troubleshoot an issue for a customer. Environment is Oracle 10.2.0.4 (64-bit) on Redhat 5. Two node RAC cluster. The 10046 trace file shows lots of 'gc current block 2-way' waits but also a few 'gc cr failure' and 'cr request retry' waits. The 'cr request retry' waits take about 0.9 seconds each. I cannot find much if any information on these two wait events. Any help is much appreciated.
    Thanks!

    Hi,
    Also, you might need to check the protocol is being used for the interconnect communication.
    here are the steps just in case:
    $ORACLE_HOME/bin/sqlplus / as sysdba
    oradebug setmypid
    oradebug unlimit
    oradebug ipc
    oradebug TRACEFILE_NAME
    Review the file that the last oradebug gave you back.
    Metalink note 181489.1 provides some handy steps to analyze your situation. (also contains the latest supported protocols for IPC)
    Hope this helps
    Regards,
    Jozsef

  • Redo log wait event

    Hi,
    in my top evens i've:
    Top 5 Timed Events Avg %Total
    ~~~~~~~~~~~~~~~~~~ wait Call
    Event Waits Time (s) (ms) Time Wait Class
    CPU time 1,894 36.1
    log file sync 36,862 1,008 27 19.2 Commit
    db file scattered read 165,508 970 6 18.5 User I/O
    db file sequential read 196,596 857 4 16.3 User I/O
    log file parallel write 35,847 565 16 10.8 System I/O
    Log file are on a separate disks, with no activity, only 1 redo per group, and 4 groups.
    I think that 27ms for log file synch is high.
    I raised commits in sqlloader putting rows=100000 instead 30000 but it's always high.
    Which check i can perform?
    I'm on AIX 5.3 and database in 10.2.0.4.4

    Log File Sync
    The “log file sync” wait event is triggered when a user session issues a commit (or a rollback). The user session will signal or post the LGWR to write the log buffer to the redo log file. When the LGWR has finished writing, it will post the user session. The wait is entirely dependent on LGWR to write out the necessary redo blocks and send confirmation of its completion back to the user session. The wait time includes the writing of the log buffer and the post, and is sometimes called “commit latency”.
    The P1 parameter in <View:V$SESSION_WAIT> is defined as follows for this wait event:
    P1 = buffer#
    All changes up to this buffer number (in the log buffer) must be flushed to disk and the writes confirmed to ensure that the transaction is committed and will be kept on an instance crash. The wait is for LGWR to flush up to this buffer#.
    Reducing Waits / Wait times:
    If a SQL statement is encountering a significant amount of total time for this event, the average wait time should be examined. If the average wait time is low, but the number of waits is high, then the application might be committing after every row, rather than batching COMMITs. Applications can reduce this wait by committing after “n” rows so there are fewer distinct COMMIT operations. Each commit has to be confirmed to make sure the relevant REDO is on disk. Although commits can be "piggybacked" by Oracle, reducing the overall number of commits by batching transactions can be very beneficial.
    If the SQL statement is a SELECT statement, review the Oracle Auditing settings. If Auditing is enabled for SELECT statements, Oracle could be spending time writing and commit data to the AUDIT$ table.
    If the average time waited is high, then examine the other log related waits for the session, to see where the session is spending most of its time. If a session continues to wait on the same
    If the average time waited is high, then examine the other log related waits for the session, to see where the session is spending most of its time. If a session continues to wait on the same buffer# then the SEQ# column of V$SESSION_WAIT should increment every second. If not then the local session has a problem with wait event timeouts. If the SEQ# column is incrementing then the blocking process is the LGWR process. Check to see what LGWR is waiting on as it may be stuck. If the waits are because of slow I/O, then try the following:
    Reduce other I/O activity on the disks containing the redo logs, or use dedicated disks.
    Try to reduce resource contention. Check the number of transactions (commits + rollbacks) each second, from V$SYSSTAT.
    Alternate redo logs on different disks to minimize the effect of the archiver on the log writer.
    Move the redo logs to faster disks or a faster I/O subsystem (for example, switch from RAID 5 to RAID 1).
    Consider using raw devices (or simulated raw devices provided by disk vendors) to speed up the writes.
    See if any activity can safely be done with NOLOGGING / UNRECOVERABLE options in order to reduce the amount of redo being written.
    See if any of the processing can use the COMMIT NOWAIT option (be sure to understand the semantics of this before using it).
    Check the size of the log buffer as it may be so large that LGWR is writing too many blocks at one time. 

  • Streams AQ wait event on Oracle 10g

    Hello,
    I have ECC 6.0 on W2k3 with Oracle. I have some wait event about Streams AQ :
    Streams AQ: waiting for messages in the queue
    Streams AQ: qmn slave idle wait
    Streams AQ: qmn coordinator waiting for slave to start
    What does it mean ? What can I do to fix that?
    From what I read, it's seems to have something to do with parameter : aq_tm_processes
    What this parameter whould be set to? It seems to be set to O now.
    Thank you for any help,
    Nicholas

    Hi,
    What is the Patch Level of Oracle 10g which is in use ?
    Please refer Oracle Meta link 428441.1 to get more information. It will tell you the reason and the possible alternatives to deal with it. You can refer SAP Note 758563 to get Oracle Meta link access.
    Unless you use Oracle Streams Advanced Queuing , there's no need to set this parameter.
    If AQ_TM_PROCESSES is not specified or is set to 0, then the queue monitor is not created.
    In 10gR2 parameter AQ_TM_PROCESSES shouldn't be set explicitly in pfile/spfile, because Oracle autotunes it.
    Also refer the [this link|SRM Alert Management does not determine recipient runtime?; to get more info.
    Regards,
    Bhavik G. Shroff

Maybe you are looking for

  • HMC150 Footage ok in PProCS4, but grey when viewing via Win Media Player

    I just purchased an HMC150 and really like it and I am recording in 1080P 24 and pulling it into a 1080P/24 timeline.  I can edit and view the media no problem in Premiere with full color, but if I play the original raw AVCHD original files through W

  • Does control comes back to servlet after redirecting to a jsp page.

    Hi I have a query on request dispatcher. I have redirected control to a jsp page in my java class as below. HttpServletRequest request=null;      HttpServletResponse response=null;      RequestDispatcher requestDispatcher = request.getRequestDispatch

  • ALE/ IDOC CONFIGURATION OBJECT

    IT'S URGENT   I NEED AN OBJECT IN ALE/IDOC CONFIGURATION SETTINGS

  • How to delete the line between the last point and first point?

    How to delete the line between the last point and first point?  I want to draw a curve many times, from first point to the end point. and redraw from first point to the end point.But I hope update point by point. but between the end point and the fir

  • MIGO screen display settings

    All, After going to MIGO screen ,below 'show overview' , we can find the field where we can select Goods Receipt or Display etc . In my setting its coming as 'A01 Goods Receipt' , A02 Display' etc . How to make the settings so that I can remove 'A01'