Transaction Identifier - ITL

The transaction id in the ITL contains the address of the undo segment number, slot number and wrap. I can infer that the undo segment number tells a transaction where to find a consistent read copy of the row(s) but cannot and do not want to guess what slot number and wrap are. I was reading an article on ITLs and the author says "When a transaction modifies a block (insert, delete or update) it records the transaction identifier in the ITL* of that datablock which is the part of variable header .... The transaction identifier contains the address of the rollback segment number (USN), slot number and wrap number.".
Link -> The article I was reading about this is here --> http://www.revealnet.com/newsletter/Transaction%20Management.htm.
Matt

Hi Matt,
The undo segment number, slot, and wrap (or sequence) make up a transaction id, and uniquely identify a transaction.
The undo segment number is just what it sounds like: The number of the undo segment being used. (Visible in dba_rollback_segs.segment_id)
The undo slot is the slot number in the undo segment header that the current transaction has reserved.
Finally, the wrap or sequence is simply a counter. Since transactions can recycle and reuse a specific undo segment number and slot combination, the wrap is simply incremented each time that specific slot in that specific segment is reused. It's just there to distinguish the transaction from the previous transaction that used the same slot previously.
Interesting bit of trivia, that's almost certainly no longer relevant. Before the days of automatic undo, when we all had to manually create and manage rollback segments, it was possible to "wear out" a rollback segment. The wrap is a 4 byte (32 bit) integer. So, if you ever used a slot in a rollback segment 2^32 (something over 4 billion) times, the rollback segment would need to be dropped, and a new one created. I just looked it up, it's an ORA-1558 that is raised when that happens. I just checked, and the error number/message still exists in 11g, though with Automatic Undo Management, I suspect you'll never see it occur.
-Mark

Similar Messages

  • Error while calling Receipt Un-application :Customer Transaction Identifier has taken a precedence over the transaction number

    Hi All,
    While calling the receipt Un-application API, I am getting a error like' Customer Transaction Identifier has taken a precedence over the transaction number'
    Kindly suggest as to how can I troubleshoot this?
    Appreciate your valuable Inputss

    Hi,
    i recommend having a Service request logged for this issue, as from related documentations in metalink most of them seemed to be a bug where oracle suggested patches (code Fixes) ... hence reaching oracle support would be a better approach ...
    Regards,
    Ivruksha

  • How to provide access to Critical Transactions in GRC AC 10.0

    +Hello Gurus,+
    +We are in phase of implementing GRC AC 10.0 , and have a requirement where there are "Critical Transactions" identified by the Business and if there is any end user who wants to access any specific "Critical Transaction" e.g. PA30 etc then it must automatically go to a specific Owner of that transaction.+
    +As far as i know , we can have a workflow for getting a role assigned, but not sure if it is possible to have a workflow where every "critical transaction" will have an owner and then on selection of the transaction it will trigger a workflow.+
    +I would also like to know what is a standard or rather best practice in SAP GRC , regarding providing access to "CRITICAL Transactions" ??+
    +We thought of creating a role containing multiple "Critical transactions" and then assigning to the firefighter ID , for which we have an approval workflow !! But that does not help , as assigning the role will give user access to some other "critical transactions" as well which we would like to control.+
    +Looking forward to know about the suggestion/solution for this issue.+
    +Thanks in advance.+
    +Regards,+
    +Victor+

    Hello,
    Victor Ger wrote:
    > +We thought of creating a role containing multiple "Critical transactions" and then assigning to the firefighter ID , for which we have an approval workflow !! But that does not help , as assigning the role will give user access to some other "critical transactions" as well which we would like to control.+
    > +Victor+
    I think that only one firefighter with all the critical transactions is not a good idea. I guess it's better to have different firefighters IDs assigned to different users. The point here is to decide if you really want to have a trace for all critical transactions executions.
    An example:
    Tx. SM37 is considered a critical transaction if the user has also the auth. object S_BTCH_ADM set to "yes".  This allows to delete or copy others user's jobs. This is and authorization that a Basis person must have. Do you really want to trace this?
    I think that force a Basis person to use a firefighter for this is nonsense, because this tx. is part of his/her job. Then, you should accept this sort of risks, otherwise you'll get the point where you replace the normal users with FF users. This is not the idea of FF.
    Of course, this is just a thought and all depends on your business requirements.
    Cheers,
    Diego.

  • How to include hidden/protected transaction ID in email?

    I'm working on an application that includes a requirement for an email based send and response mechanism.
    Ideally I'd like to include somewhere within this email a transaction code that allows me to identify the target user response.
    What's the best method for achieving this? Can I for example include the transaction ID as an custom entry in the email header?
    What I'd like is some way of ensuring that the target user cannot interfere with the transaction identifier.

    I cannot check at the moment, but I think the parameter is called xCollectionPath.
    However, I think you will need a bit more than just the mere string - there is a chance to create a link to the folder (a shortcut), which enable one-click opening the folder. It will require a bit more work.

  • EBS MT940 Ext Transaction Problem

    Dear Gurus,
    I have completed all config for MT940 upload and small sample statement worked fine but today testing with real EBS from bank found a typical issue.
    For the EBS SAP is reading Ext transaction from the :86: line.
    For Example:
    :20:20081110
    :25:126367007
    :28:89
    :60F:C081008THB137,14
    :61:0810141014CB10,NCMZNONREF//0000300382
    :86:/PT/DE/EI//BRC/0140014
    :62F:C081008THB147,14
    :86: item SAP gives msg as /PT ext transaction not defined in table.................
    Ext tran are taken from :61:line why its taking from 86  I am confused::
    But surprising is that in case of small test statement with little line items it was not happening.Is there anything to do do with the file (notepad)properties ?Please suugest.
    Regards
    Raju

    Hi,
    :61: contains only the transaction details and not the external transaction.  The external transaction also called the Business Code is always taken from the first three characters of the :86: line.  The :61: only contains the following:
    mandatory:
    <CR><LF>:61:                      Transaction line
    Value-date                             exactly 6 characters numeric in the format YYMMDD
    optional:
    Booking date                         exactly 4 characters numeric
    mandatory:
    Debit/credit mark                  1 to 2 characters
                                                C         =   Credit
                                                RC      =   Reversal credit
                                                D         =   Debit
                                                RD      =   Reversal debit
    optional:
    Currency type                        1 Characters alphanumeric
    mandatory:
    Amount                                 1 to 15 characters numeric
                                                   amount with , (comma) as decimal point
    Booking code .                      exactly 4 characters alphanumeric
                                                codes according to Swift, 1. character always N
    Reference                              1 to 16 Characters alphanum.
    Customer reference; if not present, replaced by NONREF
    //                                              Delimiter; only if field "Bank reference" present
    Cont. :61:
    You need to map the external transaction in the node Make Global Settings for Electronic Bank Statement in the Bank Accounting IMG.
    In there, you have an option to assign external transaction types to your posting rules.  This decides how an external transaction, identified by this mapping, is to be posted, whether to the bank account or subledger account etc etc.  So you need to assign /PT here to a posting rule.
    Cheers.

  • Transactional  RFC material (urgent)

    Hi gurus,
    i need some good matrial on Transactional Remote Function Call. Please provide me  the same,
    any help will be highly appreciated
    Regards
    vj

    hi vj,
    Transactional RFC
    1 This type of RFC was renamed from asynchronous to transactional RFC, because asynchronous RFC has another meaning in R/3 Systems.
    2 The called function module is executed exactly once in the RFC server system. Each function call is seen as a transaction in the target system.
    3 Transactional RFCs use the suffix IN BACKGROUND TASK. The remote system need not be available at the time when the RFC client program is executing a tRFC.
    4 The tRFC component stores the called RFC function together with the corresponding data in the R/3 database, including a unique transaction identifier (TID).
    5 If a call is sent, and the receiving system is down, the call remains in the local queue until a later time.
    6 The calling dialog program can proceed without waiting to see whether or not the remote call was successful. If the receiving system does not become active within a certain amount of time, the call is scheduled to run in batch.
    7 The system logs the remote call request in the database tables ARFCSSTATE and ARFCSDATA with all of its parameter values. You can display the log file using transaction SM58.
    8 When the calling program reaches a COMMIT WORK, the remote call is forwarded to the requested system for execution.
    9 Transactional RFC requests are transferred, with parameter data in byte-stream form, using TCP/IP or X400.
    10 LUW's are identified by transaction ID's that are unique world-wide. The transaction ID can be determined from an ABAP program by calling function module ID_OF_BACKGROUNDTASK. (You must call this function after the first asynchronous CALL, and before the related COMMIT WORK.)
    11 The system function module ARFC_DEST_SHIP transports the data to the target system and the function module ARFC_EXECUTE executes the stored function calls. If an error or an exception occurs during one of the calls, all the database operations started by the preceding calls are rolled back and an appropriate error message is written to the file ARFCSSTATE.
    12 Once you have identified the ID of the LUW, you can use the function module STATUS_OF_BACKGROUNDTASK to determine the status of the transactional RFC.
    13 Call transaction SM58 (Tools _ Administration _ Monitoring _ Transactional RFC). This tool lists only those transactonal RFCs that could not be carried out successfully or that had to be planned as batch jobs. The list includes the LUW ID and an error message. Error messages displayed in SM58 are taken from the target system. To display the text of the message, double-click on the message.
    14 If a LUW runs successfully in the target system, the function module ARFC_DEST_CONFIRM is triggered and confirms the successful execution in the target system. Finally, the entries in the Tables ARFCSSTATE and ARFCSDATA are deleted.
    DISADVANTAGES
    1 These can reduce performance significantly in both the send and the target
    systems.
    2 In addition, the sequence of LUWs defined in the application cannot be kept. Therefore, there is no guarantee that the transactions are executed in the sequence dictated by the application. The only guarantee is that all LUWs are transferred sooner or later.
    SYNTAX
    Eg : CALL FUNCTION ‘remotefunction’ IN BACKGROUND TASK
    CALL FUNCTION func IN BACKGROUND UNIT
    parameter_list. The field ‘dest’ can be either a literal or a variable. Logical destinations are defined in the RFCDES table via transaction SM59 or via the menu path: Tools ->Administration,Administration->Network->RFC destinations.
    SAMPLE PROGRAM
    RSTRFCT0
    regards
    gaurav
    <b>plz award pts if helpfull</b>

  • Error in Extend IDOC in WE30 Transaction

    Hi Gurus.
    When I am creating an extension in WE30 transaction, the message is displayed:
    "Action is Not Possible for generated idoctypes"
    Debugging the transaction, identify the DataBase table EDBAS, What has the field "GENERATED" marked with "X" for Basic Type used.
    How i Create the Extension for this Idoc  ?
    Basic Type: SALESORDER_CREATEFROMDAT202
    Please Help-me.
    Tks.
    André Almeida

    Hi,
    You can not extend the Generated IDOC types but you can use the E1BPEXT E1BPEXTC segment that is given by SAP for customer enhancement.
    If you really want to extend the IDOC then
    1> Extension can not be done by we30 but you have to create the subtype of the corresponding business object.
    2> go to BDBG transaction code and regenerate this again
    3 > here you have to give new message type then again you have to proceed accordingly.
    have a look on the link.
    http://help.sap.com/saphelp_47x200/helpdata/en/4c/4c0e9c725311d396a80004ac96334b/frameset.htm
    regards
    Prince

  • Managing rightly the transaction log of a db for a massive import to avoid storage saturation

    Hi,
    I'm working on a virtual production SQL Server environment that hosts 10-15 databases. The data storage has a capacity about 400-500 GB. All databases are in simple recovery model. A my procedure on a my db (in simple recovery mode) reads 4-5 millions of
    row data from 4-5 Oracle tables having 20-30 columns. The SQL Server stored procedure is called by a SSIS 2012 task. During the procedure execution, the transaction log of my db is increased exceeding 120-130 GB. This growth has caused a storage saturation
    not pleasant for my customer.
    So, my customer has asked me to investigate about the right management of the transaction log growth. In particular, is it possible to avoid to write in the transaction log for a certain procedure or T-SQL operation? My customer has experienced with the
    Oracle dbms and has said me that Oracle manages better the storage space also with blob fields.
    Also if it is possible to perform a shrink operation for the transaction log, it is need to avoid the exponential growth of the transaction log before that the storage saturates.
    Any helps to me, please? Many thanks

    Hi,
    Please monitor  hung transactions which are  causing high transaction log utilization.
    Also you need to look with capacity planning perspective where you need to identify the transaction with highest transaction log requirement. Accordingly you need to set the size of Transaction log. Also you can set the Autogrowth option for transaction
    log based on best practices.
    Please check when is the auto checkpoint takes place I mean default recovery interval in your settings.
    Because in simple recovery model auto checkpoint takes place based upon recovery interval/% Transaction log used. 
    If the log has swollen then as a weekly maintenance you can shrink the transaction log size based upon your transaction requirements.
    overall better monitoring of your running transactions ,Identify any hung transactions find the root cause,
    proper log auto growth setttings will overcome most of your problem.

  • Log the Container managed Transaction ID

    Can I somehow log the Container managed Transaction ID (or some transaction
              identifier) for the method (when I encounter some problems and I am debuging
              it) or how do I get a reference to the TransactionManager object inside the
              weblogic server to fetch it.
              

    What version of WLS are you using?
              WLS 6 lets you get a reference to the TransactionManager or the current
              transaction. Take a look at the JTA docs for more info.
              -- Rob
              Stefan Tamasi wrote:
              >
              > Can I somehow log the Container managed Transaction ID (or some transaction
              > identifier) for the method (when I encounter some problems and I am debuging
              > it) or how do I get a reference to the TransactionManager object inside the
              > weblogic server to fetch it.
              Coming Soon: Building J2EE Applications & BEA WebLogic Server
              by Michael Girdley, Rob Woollen, and Sandra Emerson
              http://learnweblogic.com
              

  • Statspack interpretation

    I have been running statspack regularly and need help in interpretation. I believe the database in question is running ok from user's point of view. However, we will be doubling the users in a few weeks and I am trying to be proactive about preparing for this. I have looked at the statspack reports and have sent them through oraperf.com, but I still have questions. Can anyone help? I can share a couple of statspack reports with specific questions. Thanks in advance, Kim

    This is a good reference to interpret Statspack.
    Perspective EXPERT ADVICE
    Advanced Tuning with Statspack
    By Rich Niemiec
    But wait, there's more! What waits mean in Statspack reports and how to tune them out.
    If you could choose just two Oracle utilities to find and monitor performance problems in your Oracle9i Database system, those two utilities would be Oracle Enterprise Manager (now available in Release 4.0) and Statspack. As of Oracle8i Release 8.1.6, the Statspack utility replaced the UTLBSTAT/UTLESTAT scripts available for performance monitoring with earlier versions of Oracle Database; Statspack offers several significant enhancements to those scripts. This column focuses on solutions to advanced issues regarding wait events—those events for which your system had to wait during processing for a resource to become available, an action to complete, and so on.
    Top 5 Wait Events
    When you are trying to eliminate bottlenecks on your system, your Statspack report's Top 5 Wait Events section is the first place to look. This section of the report shows the top 5 wait events, the full list of wait events, and the background wait events. If your system's TIMED_STATISTICS initialization parameter is set to true, the events are ordered in time waited, which is preferable, since all events don't show the waits. If TIMED_STATISTICS is false, the events are ordered by the number of waits.
    Listing 1 shows a large number of waits related to reading a single block (db file sequential read) as well as waits for latches (latch free). You can see in this listing high waits for some of the writing to datafiles and log files. To identify which of these are major issues, you must narrow down the list by investigating the granular reports within other sections of Statspack.
    Resolving Your Wait Events
    The following are 10 of the most common causes for wait events, along with explanations and potential solutions:
    1. DB File Scattered Read. This generally indicates waits related to full table scans. As full table scans are pulled into memory, they rarely fall into contiguous buffers but instead are scattered throughout the buffer cache. A large number here indicates that your table may have missing or suppressed indexes. Although it may be more efficient in your situation to perform a full table scan than an index scan, check to ensure that full table scans are necessary when you see these waits. Try to cache small tables to avoid reading them in over and over again, since a full table scan is put at the cold end of the LRU (Least Recently Used) list.
    2. DB File Sequential Read. This event generally indicates a single block read (an index read, for example). A large number of waits here could indicate poor joining orders of tables, or unselective indexing. It is normal for this number to be large for a high-transaction, well-tuned system, but it can indicate problems in some circumstances. You should correlate this wait statistic with other known issues within the Statspack report, such as inefficient SQL. Check to ensure that index scans are necessary, and check join orders for multiple table joins. The DB_CACHE_SIZE will also be a determining factor in how often these waits show up. Problematic hash-area joins should show up in the PGA memory, but they're also memory hogs that could cause high wait numbers for sequential reads. They can also show up as direct path read/write waits.
    3. Free Buffer. This indicates your system is waiting for a buffer in memory, because none is currently available. Waits in this category may indicate that you need to increase the DB_BUFFER_CACHE, if all your SQL is tuned. Free buffer waits could also indicate that unselective SQL is causing data to flood the buffer cache with index blocks, leaving none for this particular statement that is waiting for the system to process. This normally indicates that there is a substantial amount of DML (insert/update/delete) being done and that the Database Writer (DBWR) is not writing quickly enough; the buffer cache could be full of multiple versions of the same buffer, causing great inefficiency. To address this, you may want to consider accelerating incremental checkpointing, using more DBWR processes, or increasing the number of physical disks.
    4. Buffer Busy. This is a wait for a buffer that is being used in an unshareable way or is being read into the buffer cache. Buffer busy waits should not be greater than 1 percent. Check the Buffer Wait Statistics section (or V$WAITSTAT) to find out if the wait is on a segment header. If this is the case, increase the freelist groups or increase the pctused to pctfree gap. If the wait is on an undo header, you can address this by adding rollback segments; if it's on an undo block, you need to reduce the data density on the table driving this consistent read or increase the DB_CACHE_SIZE. If the wait is on a data block, you can move data to another block to avoid this hot block, increase the freelists on the table, or use Locally Managed Tablespaces (LMTs). If it's on an index block, you should rebuild the index, partition the index, or use a reverse key index. To prevent buffer busy waits related to data blocks, you can also use a smaller block size: fewer records fall within a single block in this case, so it's not as "hot." When a DML (insert/update/ delete) occurs, Oracle Database writes information into the block, including all users who are "interested" in the state of the block (Interested Transaction List, ITL). To decrease waits in this area, you can increase the initrans, which will create the space in the block to allow multiple ITL slots. You can also increase the pctfree on the table where this block exists (this writes the ITL information up to the number specified by maxtrans, when there are not enough slots built with the initrans that is specified). Next Steps
    READ MORE about Statspack
    In "Performance Tuning with Statspack" on OTN
    /deploy/performance/pdf/
    statspack_tuning_otn_new.pdf
    In Rich Niemiec's "Oracle Performance Tuning Tips and Techniques," available from Amazon.com
    amazon.com/oracle
    GET SUPPORT from MetaLink
    oracle.com/support/metalink/index.html
    GET EDUCATED on Oracle9i
    /oramag/oracle/searchou.html
    5. Latch Free. Latches are low-level queuing mechanisms (they're accurately referred to as mutual exclusion mechanisms) used to protect shared memory structures in the system global area (SGA). Latches are like locks on memory that are very quickly obtained and released. Latches are used to prevent concurrent access to a shared memory structure. If the latch is not available, a latch free miss is recorded. Most latch problems are related to the failure to use bind variables (library cache latch), redo generation issues (redo allocation latch), buffer cache contention issues (cache buffers LRU chain), and hot blocks in the buffer cache (cache buffers chain). There are also latch waits related to bugs; check MetaLink for bug reports if you suspect this is the case (oracle.com/support). When latch miss ratios are greater than 0.5 percent, you should investigate the issue. I will cover latch waits in detail in my next Oracle Magazine column; the topic requires an article in itself.
    6. Enqueue. An enqueue is a lock that protects a shared resource. Locks protect shared resources, such as data in a record, to prevent two people from updating the same data at the same time. An enqueue includes a queuing mechanism, which is FIFO (first in, first out). Note that Oracle's latching mechanism is not FIFO. Enqueue waits usually point to the ST enqueue, the HW enqueue, the TX4 enqueue, and the TM enqueue. The ST enqueue is used for space management and allocation for dictionary-managed tablespaces. Use LMTs, or try to preallocate extents or at least make the next extent larger for problematic dictionary-managed tablespaces. HW enqueues are used with the high-water mark of a segment; manually allocating the extents can circumvent this wait. TX4s are the most common enqueue waits. TX4 enqueue waits are usually the result of one of three issues. The first issue is duplicates in a unique index; you need to commit/rollback to free the enqueue. The second is multiple updates to the same bitmap index fragment. Since a single bitmap fragment may contain multiple rowids, you need to issue a commit or rollback to free the enqueue when multiple users are trying to update the same fragment. The third and most likely issue is when multiple users are updating the same block. If there are no free ITL slots, a block-level lock could occur. You can easily avoid this scenario by increasing the initrans and/or maxtrans to allow multiple ITL slots and/or by increasing the pctfree on the table. Finally, TM enqueues occur during DML to prevent DDL to the affected object. If you have foreign keys, be sure to index them to avoid this general locking issue.
    7. Log Buffer Space. This wait occurs because you are writing the log buffer faster than LGWR can write it to the redo logs, or because log switches are too slow. To address this problem, increase the size of the log files, or increase the size of the log buffer, or get faster disks to write to. You might even consider using solid-state disks, for their high speed.
    8. Log File Switch. All commit requests are waiting for "logfile switch (archiving needed)" or "logfile switch (chkpt. Incomplete)." Ensure that the archive disk is not full or slow. DBWR may be too slow because of I/O. You may need to add more or larger redo logs, and you may potentially need to add database writers if the DBWR is the problem.
    9. Log File Sync. When a user commits or rolls back data, the LGWR flushes the session's redo from the log buffer to the redo logs. The log file sync process must wait for this to successfully complete. To reduce wait events here, try to commit more records (try to commit a batch of 50 instead of one at a time, for example). Put redo logs on a faster disk, or alternate redo logs on different physical disks, to reduce the archiving effect on LGWR. Don't use RAID 5, since it is very slow for applications that write a lot; potentially consider using file system direct I/O or raw devices, which are very fast at writing information.
    10. Idle Event. There are several idle wait events listed after the output; you can ignore them. Idle events are generally listed at the bottom of each section and include such things as SQL*Net message to/from client and other background-related timings. Idle events are listed in the stats$idle_event table.
    Stay Tuned
    In the next issue of Oracle Magazine, I'll investigate latches—another of the top waits you may encounter—looking at the usual latch waits you'll see and how to tune them for maximum performance.
    Rich Niemiec is the CEO of TUSC (www.tusc.com) and president of the International Oracle Users Group (www.ioug.org). Thanks to Steve Adams for editing help.
    Wait Events Quick Reference Guide
    Wait Problem Potential Fix
    DB File Scattered Read Indicates many full table scans: tune the code; cache small tables.
    DB File Sequential Read Indicates many index reads: tune the code (especially joins).
    Free Buffer Increase the DB_CACHE_SIZE; shorten the checkpoint; tune the code.
    Buffer Busy Segment header: add freelists or freelist groups.
    Buffer Busy Data block: separate "hot" data; use reverse key indexes and/or smaller blocks.
    Buffer Busy Data block: increase initrans and/or maxtrans.
    Buffer Busy Undo header: add rollback segments or areas.
    Buffer Busy Undo block: commit more often; use larger rollback segments or areas.
    Latch Free Investigate the latch detail.
    Enqueue—ST Use LMTs or preallocate large extents.
    Enqueue—HW Preallocate extents above high-water mark.
    Enqueue—TX4 Increase initrans and/or maxtrans on the table or index.
    Enqueue—TM Index foreign keys; check application locking of tables.
    Log Buffer Space Increase the log buffer; use faster disks for the redo logs.
    Log File Switch Archive destination slow or full; add more or larger redo logs.
    Log File Sync Commit more records at a time; use faster redo log disks or raw devices.
    Idle Event Ignore it.
    Common Idle Events
    Event Idle Event Type
    Dispatcher timer Shared server
    Lock manager wait for remote message Oracle9i Real Application Clusters
    Pipe get User process
    pmon timer Background process
    PX Idle wait Parallel query
    PX Deq Credit: need buffer Parallel query
    PX Deq Credit: send blkd Parallel query
    rdbms ipc message Background process
    smon timer Background process
    SQL*Net message from client User process
    virtual Circuit status Shared server
    http://otn.oracle.com/oramag/oracle/03-jan/o13expert.html
    Joel Pérez

  • Locking and blocking - puzzlement.

    I have a table - relatively simple
    CREATE TABLE Sysstat
    M_Time     DATE,
    Usr_pct    NUMBER(10, 0),
    Sys_pct    NUMBER(10, 0),
    <a few more NUMBER(10, 0) deleted...
    CONSTRAINT Sysstat_PK PRIMARY KEY (M_Time)
    );Issue (From an SQLPlus session) the command DELETE FROM Sysstat - but do not COMMIT.
    Go to SQLDeveloper - and (try to) do the following
    INSERT INTO Sysstat
    SELECT ROUND(TO_DATE  (Sysstat_ext.M_Time, 'DD-MM HH24:MI:SS'), 'MI') AS "Measurement Time",
           ROUND(TO_NUMBER(Sysstat_ext.Usr_pct),    0) AS "% Usr",
           <fields deleted>
    FROM Sysstat_ext
    COMMIT;The SQLDeveloper session completely hangs - forever* (at least 20 mins at this stage).
    As I understood matters with Oracle there were three possibilities.
    1) PK violation. The SQLDeveloper session "sees" that there are still records in Sysstat (changes
    are uncommitted as far as he's concerned), but there is a PK violation in the data to
    be inserted anyway, so the SQLDeveloper session should tell the user Sysstat_PK violation.... error...
    2) No potential PK violation. The SQLDeveloper session doesn't know whether the SQL*Plus
    session will commit its deletions or not, therefore the SQLDeveloper session commits and Oracle keeps track of the
    necessary chains of pointers internally and/or when the SQL*Plus session tries to commit, it's accepted or refused
    depending on whether this will cause other issues (FK violation for example)
    or
    3) Oracle knows that there's a deadlock and after a certain period (configurable?) rolls back the SQLDeveloper session
    and informs the user.
    Could some kind soul explain to me what, exactly, is going on - and why my reasoning is so obviously erroneous.
    I have been looking at Kyte's architecture book, so maybe a concrete example (I've never deadlocked Oracle
    before) would help clarify the concepts for me.
    Paul...

    Paulie wrote:
    >
    Could some kind soul explain to me what, exactly, is going on - and why my reasoning is so obviously erroneous.
    I have been looking at Kyte's architecture book, so maybe a concrete example (I've never deadlocked Oracle
    before) would help clarify the concepts for me.I've now read a bit about mutexes in Oracle - not that I understood all of it.
    no deadlock is occuring.Well, what else should one call a session that is blocked indefinitely? Is there another
    computer science term for this phenomenon?
    I suspect a Mutex wait is the cause.OK - so, some sort of device to "regulate concurrent access to a shared resource". That's fine.
    The blogs and websites which discuss this seem to be a propeller-head's wet dream with obscure X$_Blah
    table configs and Totallyunknown_even_to_Oracle_Support parameters being bandied about like there's
    no tomorrow.
    What I would like to know is a bit more prosaic (and perhaps a level less technically sophisticated).
    Is my reading of Oracle's Locking/Latching/Multi-User behaviour correct in what I wrote originally, i.e.
    Scenarios:
    1) PK violation. The SQLDeveloper session "sees" that there are still records in Sysstat (deletion
    is uncommitted as far as he's concerned), but there is a PK violation in the data to
    be inserted anyway, so the SQLDeveloper session should tell the user Sysstat_PK violation.... error...
    no change to database - SQLDev user informed
    2) No potential PK violation. The SQLDeveloper session doesn't know whether the SQL*Plus
    session will commit its deletions or not, therefore the SQLDeveloper session commits and Oracle keeps track of the
    necessary chains of pointers internally and/or when the SQL*Plus session tries to commit, it's accepted or refused
    depending on whether this will cause other issues (FK violation for example)
    or
    3) Oracle knows that there's a deadlock and after a certain period (configurable?) rolls back the SQLDeveloper session
    and informs the user.
    Or am I still competely at sea with what Oracle is about? I was of the understanding that whatever* happened,
    you should never have a situation where a session hangs indefinitely, due to Oracle's system
    of multi-version concurrency - basically, I'm asking what is going on here and how does it
    fit with my current* (and obviously mistaken) understanding of how Oracle works.
    Thanks for your input so far.
    Paul...A basic truism exist for Oracle.
    Readers do not block writers & writers do not block readers!
    What you fail to recognize is that your test case has two WRITERS; both are doing DML!
    two sessions want to change same resource & to maintain data consistency & integrity
    the changes must be serialized. One must complete before the second can proceed.
    Oracle utilizes Interested Transaction List (ITL) to maintain block level data consistency.
    SELECT DECODE(request,0,'Holder: ','Waiter: ')||sid sess,
    id1, id2, lmode, request, type
    FROM V$LOCK
    WHERE (id1, id2, type) IN
    (SELECT id1, id2, type FROM V$LOCK WHERE request>0)
    ORDER BY id1, request
    /

  • ORA-01403: no data found in alert.log

    Dear All,
    I am getting ORA-01403: no data found in alert.log.Could you pls help me out what could be reasons behind it..Due to this i m getting loads of alerts.Pls suggest.
    Thanks

    ORA-01403 No Data Found
    Typically, an ORA-01403 error occurs when an apply process tries to update an existing row and the OLD_VALUES in the row LCR do not match the current values at the destination database.
    Typically, one of the following conditions causes this error:
    Supplemental logging is not specified for columns that require supplemental logging at the source database. In this case, LCRs from the source database might not contain values for key columns. You can use a DML handler to modify the LCR so that it contains the necessary supplemental data. See "Using a DML Handler to Correct Error Transactions". Also, specify the necessary supplemental logging at the source database to prevent future errors.
    There is a problem with the primary key in the table for which an LCR is applying a change. In this case, make sure the primary key is enabled by querying the DBA_CONSTRAINTS data dictionary view. If no primary key exists for the table, or if the target table has a different primary key than the source table, then specify substitute key columns using the SET_KEY_COLUMNS procedure in the DBMS_APPLY_ADM package. You also might encounter error ORA-23416 if a table being applied does not have a primary key. After you make these changes, you can reexecute the error transaction.
    The transaction being applied depends on another transaction which has not yet executed. For example, if a transaction tries to update an employee with an employee_id of 300, but the row for this employee has not yet been inserted into the employees table, then the update fails. In this case, execute the transaction on which the error transaction depends. Then, reexecute the error transaction.
    There is a data mismatch between a row LCR and the table for which the LCR is applying a change. Make sure row data in the table at the destination database matches the row data in the LCR. When you are checking for differences in the data, if there are any DATE columns in the shared table, then make sure your query shows the hours, minutes, and seconds. If there is a mismatch, then you can use a DML handler to modify an LCR so that it matches the table. See "Using a DML Handler to Correct Error Transactions".
    Alternatively, you can update the current values in the row so that the row LCR can be applied successfully. If changes to the row are captured by a capture process at the destination database, then you probably do not want to replicate this manual change to destination databases. In this case, complete the following steps:
    Set a tag in the session that corrects the row. Make sure you set the tag to a value that prevents the manual change from being replicated. For example, the tag can prevent the change from being captured by a capture process.
    EXEC DBMS_STREAMS.SET_TAG(tag => HEXTORAW('17'));
    In some environments, you might need to set the tag to a different value.
    Update the row in the table so that the data matches the old values in the LCR.
    Reexecute the error or reexecute all errors. To reexecute an error, run the EXECUTE_ERROR procedure in the DBMS_APPLY_ADM package, and specify the transaction identifier for the transaction that caused the error. For example:
    EXEC DBMS_APPLY_ADM.EXECUTE_ERROR(local_transaction_id => '5.4.312');
    Or, execute all errors for the apply process by running the EXECUTE_ALL_ERRORS procedure:
    EXEC DBMS_APPLY_ADM.EXECUTE_ALL_ERRORS(apply_name => 'APPLY');
    If you are going to make other changes in the current session that you want to replicate destination databases, then reset the tag for the session to an appropriate value, as in the following example:
    EXEC DBMS_STREAMS.SET_TAG(tag => NULL);
    In some environments, you might need to set the tag to a value other than NULL.

  • Table control as non editable

    Hi experts,
                    I need make my table control as noneditable for a specific transaction after fetching values.
    i did till fetching part and displaying in table control. but its diplaying as editable field. i need to make that as non editable... plz help me in this....this screen is for only dispaly purpose...
    Note:- i did Table control through wizard...

    Based on your transaction identifier , and also give the Screen group1 for all the columns ex: AAA you can do some thing like this in the PBO
    PBO
    Loop at itab with control tc.
    module input_enable_disable.
    endloop.
    module input_enable_disable output.
    if Transaction = 'DISP'.
    loop at screen.
      if screen-group = 'AAA'.
       screen-input = 0.
       modify screen.
      endif.
    endloop.
    endif.
    endmodule.

  • High Logical I/O

    Hello,
    The system we use is a kind of OLTP thing.
    platform - linux
    version - 10.2
    here, in the statspack everything seems okay to me except the logical reads.(if not tell)
    the problems is, the cpu grows gradually and reaches 100.
    i need the cpu to be steady.
    can somebody tell what is happening here?
    STATSPACK report for
    Database DB Id Instance Inst Num Startup Time Release RAC
    ~~~~~~~~ ----------- ------------ -------- --------------- ----------- ---
    2386172435 apple22a 1 11-Aug-09 23:14 10.2.0.1.0 NO
    Host Name: xxxxxxxxx Num CPUs: 4 Phys Memory (MB): 2
    ~~~~
    Snapshot Snap Id Snap Time Sessions Curs/Sess Comment
    ~~~~~~~~ ---------- ------------------ -------- --------- -------------------
    Begin Snap: 1747 11-Aug-09 23:23:46 96 7.6
    End Snap: 1752 11-Aug-09 23:34:00 218 12.5
    Elapsed: 10.23 (mins)
    Cache Sizes Begin End
    ~~~~~~~~~~~ ---------- ----------
    Buffer Cache: 2,864M Std Block Size: 8K
    Shared Pool Size: 656M Log Buffer: 29,855K
    Load Profile Per Second Per Transaction
    ~~~~~~~~~~~~ --------------- ---------------
    Redo size: 8,051,891.15 5,042.02
    Logical reads: 289,821.64 181.48
    Block changes: 49,889.55 31.24
    Physical reads: 197.76 0.12
    Physical writes: 717.84 0.45
    User calls: 1,908.82 1.20
    Parses: 962.84 0.60
    Hard parses: 0.25 0.00
    Sorts: 591.85 0.37
    Logons: 0.35 0.00
    Executes: 25,757.48 16.13
    Transactions: 1,596.96
    % Blocks changed per Read: 17.21 Recursive Call %: 94.11
    Rollback per transaction %: 26.58 Rows per Sort: 628.58
    Instance Efficiency Percentages
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    Buffer Nowait %: 99.97 Redo NoWait %: 100.00
    Buffer Hit %: 99.93 In-memory Sort %: 100.00
    Library Hit %: 100.01 Soft Parse %: 99.97
    Execute to Parse %: 96.26 Latch Hit %: 99.78
    Parse CPU to Parse Elapsd %: 91.30 % Non-Parse CPU: 99.31
    Shared Pool Statistics Begin End
    Memory Usage %: 47.56 49.99
    % SQL with executions>1: 60.62 73.55
    % Memory for SQL w/exec>1: 77.58 84.79
    Top 5 Timed Events Avg %Total
    ~~~~~~~~~~~~~~~~~~ wait Call
    Event Waits Time (s) (ms) Time
    CPU time 1,362 31.6
    log file sync 16,960 1,264 75 29.4
    PL/SQL lock timer 10 586 58606 13.6
    buffer busy waits 57,444 388 7 9.0
    enq: TX - row lock contention 12,036 298 25 6.9
    Host CPU (CPUs: 4)
    ~~~~~~~~ Load Average
    Begin End User System Idle WIO WCPU
    0.20 10.74 53.82 9.51 36.67
    Note: There is a 8% discrepancy between the OS Stat total CPU time and
    the total CPU time estimated by Statspack
    OS Stat CPU time: 2261(s) (BUSY_TIME + IDLE_TIME)
    Statspack CPU time: 2456(s) (Elapsed time * num CPUs in end snap)
    Instance CPU
    ~~~~~~~~~~~~
    % of total CPU for Instance: 63.51
    % of busy CPU for Instance: 100.30
    %DB time waiting for CPU - Resource Mgr:
    Memory Statistics Begin End
    ~~~~~~~~~~~~~~~~~ ------------ ------------
    Host Mem (MB): 1.9 .0
    SGA use (MB): 3,584.0 3,584.0
    PGA use (MB): 164.2 258.5
    % Host Mem used for SGA+PGA: 194875.2 8987233.1
    Avg
    %Time Total Wait wait Waits
    Event Waits -outs Time (s) (ms) /txn
    log file sync 16,960 4 1,264 75 0.0
    PL/SQL lock timer 10 100 586 58606 0.0
    buffer busy waits 57,444 0 388 7 0.1
    enq: TX - row lock contention 12,036 0 298 25 0.0
    log file parallel write 11,870 0 163 14 0.0
    db file sequential read 21,324 0 95 4 0.0
    log file sequential read 3,963 0 47 12 0.0
    db file scattered read 22,614 0 29 1 0.0
    log file switch completion 102 17 28 272 0.0
    latch: cache buffers chains 5,829 0 11 2 0.0
    Log archive I/O 4,346 0 9 2 0.0
    enq: TX - index contention 1,153 0 7 6 0.0
    latch free 1,483 0 4 3 0.0
    control file parallel write 328 0 4 11 0.0
    control file sequential read 1,593 0 2 1 0.0
    latch: enqueue hash chains 337 0 2 6 0.0
    buffer deadlock 1,091 99 2 2 0.0
    Segments by Logical Reads DB/Inst: apple22A/apple22a Snaps: 1747-1752
    -> End Segment Logical Reads Threshold: 10000
    -> Pct Total shows % of logical reads for each top segment compared with total
    logical reads for all segments captured by the Snapshot
    Subobject Obj. Logical Pct
    Owner Tablespace Object Name Name Type Reads Total
    TPCCDB TPCCDB NEW_ORDER TABLE 89,638,240 51.4
    TPCCDB TPCCDB PK_STOCK INDEX 22,913,776 13.1
    TPCCDB TPCCDB PK_ORDER_LINE INDEX 14,941,264 8.6
    TPCCDB TPCCDB PK_O_ORDER INDEX 10,503,040 6.0
    TPCCDB TPCCDB ORDER_LINE TABLE 6,368,896 3.7
    Segments by Physical Reads DB/Inst: apple22A/apple22a Snaps: 1747-1752
    -> End Segment Physical Reads Threshold: 1000
    Subobject Obj. Physical Pct
    Owner Tablespace Object Name Name Type Reads Total
    TPCCDB TPCCDB NEW_ORDER TABLE 49 12.2
    TPCCDB TPCCDB WAREHOUSE TABLE 49 12.2
    TPCCDB TPCCDB DISTRICT TABLE 49 12.2
    TPCCDB TPCCDB INDEX_NO_D_ID INDEX 49 12.2
    TPCCDB TPCCDB PK_NEW_ORDER INDEX 49 12.2
    SQL Memory Statistics DB/Inst: apple22A/apple22a Snaps: 1747-1752
    Begin End % Diff
    Avg Cursor Size (KB): 65.12 67.79 3.95
    Cursor to Parent ratio: 1.03 1.02 -.08
    Total Cursors: 560 620 9.68
    Total Parents: 546 605 9.75
    init.ora Parameters DB/Inst: apple22A/apple22a Snaps: 1747-1752
    End value
    Parameter Name Begin value (if different)
    aq_tm_processes 1
    audit_file_dest /rdbms/oracle/apple22i/64/admin/o
    background_dump_dest /rdbms/oracle/apple22i/64/admin/o
    commit_write BATCH,NOWAIT
    compatible 10.2.0.1.0
    control_files /rdbms/oracle/apple22i/64/oradata
    core_dump_dest /rdbms/oracle/apple22i/64/admin/o
    cursor_sharing EXACT
    db_block_size 8192
    db_domain yyyyyyy
    db_file_multiblock_read_count 16
    db_name apple22a
    db_recovery_file_dest /rdbms/oracle/apple22i/64/flash_r
    db_recovery_file_dest_size 2147483648
    dispatchers (PROTOCOL=TCP) (SERVICE=apple22aX
    dml_locks 30028
    global_names TRUE
    job_queue_processes 10
    log_archive_dest_1 LOCATION=/perf0/Archivelog_10g_ch
    log_archive_format arch_%t_%s_%r.dbf
    log_buffer 30571520
    open_cursors 300
    pga_aggregate_target 524288000
    processes 2000
    remote_login_passwordfile EXCLUSIVE
    sessions 2205
    sga_max_size 3758096384
    sga_target 3758096384
    transactions 7507
    undo_management AUTO
    undo_tablespace UNDOTBS1
    user_dump_dest /rdbms/oracle/apple22i/64/admin/o
    -------------------------------------------------------------

    Process Memory Summary Stats  DB/Inst: apple22A/apple22a  Snaps: 2147-2151
    -> B: Begin snap   E: End snap
    -> All rows below contain absolute values (i.e. not diffed over the interval)
    -> Max Alloc is Maximum PGA Allocation size at snapshot time
       Hist Max Alloc is the Historical Max Allocation for still-connected processes
    -> Num Procs or Allocs:  For Begin/End snapshot lines, it is the number of
       processes. For Category lines, it is the number of allocations
    -> ordered by Begin/End snapshot, Alloc (MB) desc
                                                                      Hist   Num
                                              Avg    Std Dev   Max    Max   Procs
                 Alloc     Used    Freeabl   Alloc    Alloc   Alloc  Alloc    or
      Category   (MB)      (MB)      (MB)     (MB)    (MB)    (MB)    (MB)  Allocs
    B --------     192.0      95.1      8.8      2.0     6.4      51     55     97
      Other        179.0                         1.8     6.3      50     54     97
      Freeable       8.8        .0                .8      .6       2            11
      PL/SQL         2.7       1.4                .0      .0       0      0     95
      SQL            2.0       1.0                .0      .0       0      2     58
    E --------     311.2     166.7     11.3      1.4     4.3      52     55    220
      Other        284.0                         1.3     4.1      49     52    220
      Freeable      11.4        .0               1.0     1.0       3            11
      PL/SQL        10.0       5.4                .0      .0       0      0    218
      SQL            5.8       2.8                .0      .0       0      2    208
    Top Process Memory (by component)  DB/Inst: apple22A/apple22a  Snaps: 2147-2151
    -> ordered by Begin/End snapshot, Alloc (MB) desc
                            Alloc   Used   Freeabl     Max      Hist Max
         PId Category       (MB)    (MB)     (MB)   Alloc (MB) Alloc (MB)
    B      5 DBW0 --------    51.3    22.5      1.0       51.3       54.8
             Other            50.3                        50.3       53.8
             Freeable          1.0      .0                 1.0
             PL/SQL             .0      .0                  .0         .0
           6 LGWR --------    24.7    11.7       .1       24.7       25.5
             Other            24.5                        24.5       25.4
             Freeable           .1      .0                  .1
             PL/SQL             .0      .0                  .0         .0
          16 ARC0 --------    21.9    10.3       .0       21.9       21.9
             Other            21.9                        21.9       21.9
             PL/SQL             .0      .0                  .0         .0
          17 ARC1 --------    21.9    10.3       .0       21.9       21.9
             Other            21.9                        21.9       21.9
             PL/SQL             .0      .0                  .0         .0
          54 TNS V1-V3 ---     4.4     1.3      1.7        4.4        4.4
             Other             2.6                         2.6        2.6
             Freeable          1.7      .0                 1.7
             SQL                .2      .1                  .2        2.3
             PL/SQL             .0      .0                  .0         .0
          11 MMON --------     3.5     1.6      1.3        3.5        3.6
             Other             2.1                         2.1        2.1
             Freeable          1.3      .0                 1.3
             SQL                .1      .0                  .1        1.1
             PL/SQL             .0      .0                  .0         .1
           8 SMON --------     2.8      .7      1.9        2.8        2.8
             Freeable          1.9      .0                 1.9
             Other              .8                          .8         .8
             SQL                .1      .0                  .1         .6
             PL/SQL             .0      .0                  .0         .0
          10 CJQ0 --------     1.6      .6       .8        1.6        1.7
             Freeable           .8      .0                  .8
             Other              .7                          .7         .7
             SQL                .1      .0                  .1         .6
             PL/SQL             .0      .0                  .0         .0
          20 q000 --------     1.6      .7       .2        1.6        1.6
             Other             1.3                         1.3        1.3
             Freeable           .2      .0                  .2
             SQL                .1      .1                  .1         .5
             PL/SQL             .0      .0                  .0         .0
          24  ------------     1.6      .6       .3        1.6        1.6
             Other             1.2                         1.2        1.2
             Freeable           .3      .0                  .3
             SQL                .1      .0                  .1         .6
             PL/SQL             .1      .0                  .1         .1
           7 CKPT --------     1.4      .4       .8        1.4        2.3
             Freeable           .8      .0                  .8
             Other              .6                          .6        1.4
             SQL                .0      .0                  .0         .1
             PL/SQL             .0      .0                  .0         .0
           9 RECO --------     1.2      .5       .6        1.2        1.2
             Freeable           .6      .0                  .6
             Other              .5                          .5         .5
             SQL                .1      .1                  .1         .5
    Top Process Memory (by component)  DB/Inst: apple22A/apple22a  Snaps: 2147-2151
    -> ordered by Begin/End snapshot, Alloc (MB) desc
                            Alloc   Used   Freeabl     Max      Hist Max
         PId Category       (MB)    (MB)     (MB)   Alloc (MB) Alloc (MB)
    B      9 PL/SQL             .0      .0                  .0         .0
          21  ------------     1.1      .5       .0        1.1        1.1
             Other             1.0                         1.0        1.0
             PL/SQL             .0      .0                  .0         .0
             SQL                .0      .0                  .0         .2
          31  ------------     1.1      .6       .1        1.1        1.1
             Other              .9                          .9         .9
             SQL                .1      .0                  .1         .2
             Freeable           .1      .0                  .1
             PL/SQL             .1      .0                  .1         .1
    E      5 DBW0 --------    52.4    23.4      3.3       52.4       54.8
             Other            49.2                        49.2       51.5
             Freeable          3.3      .0                 3.3
             PL/SQL             .0      .0                  .0         .0
           6 LGWR --------    24.7    11.7       .1       24.7       25.5
             Other            24.5                        24.5       25.4
             Freeable           .1      .0                  .1
             PL/SQL             .0      .0                  .0         .0
          16 ARC0 --------    21.9    10.3       .0       21.9       21.9
             Other            21.9                        21.9       21.9
             PL/SQL             .0      .0                  .0         .0
          17 ARC1 --------    21.9    10.3       .0       21.9       21.9
             Other            21.9                        21.9       21.9
             PL/SQL             .0      .0                  .0         .0
          54 TNS V1-V3 ---     4.6     1.3      1.9        4.6        4.6
             Other             2.4                         2.4        2.4
             Freeable          2.1      .0                 2.1
             SQL                .1      .1                  .1        2.5
             PL/SQL             .0      .0                  .0         .0
          11 MMON --------     3.5     1.6      1.3        3.5        3.6
             Other             2.1                         2.1        2.1
             Freeable          1.3      .0                 1.3
             SQL                .1      .0                  .1        1.1
             PL/SQL             .0      .0                  .0         .1
           8 SMON --------     2.8      .7      1.8        2.8        2.8
             Freeable          1.8      .0                 1.8
             Other             1.0                         1.0        1.0
             SQL                .1      .0                  .1         .6
             PL/SQL             .0      .0                  .0         .0
          10 CJQ0 --------     1.6      .6       .8        1.6        1.7
             Freeable           .8      .0                  .8
             Other              .7                          .7         .7
             SQL                .1      .0                  .1         .6
             PL/SQL             .0      .0                  .0         .0
          20 q000 --------     1.6      .7       .2        1.6        1.6
             Other             1.3                         1.3        1.3
             Freeable           .2      .0                  .2
             SQL                .1      .1                  .1         .5
             PL/SQL             .0      .0                  .0         .0
          24  ------------     1.6      .6       .6        1.6        1.6
             Other              .9                          .9         .9
             Freeable           .6      .0                  .6
             SQL                .1      .0                  .1         .6
    Top Process Memory (by component)  DB/Inst: apple22A/apple22a  Snaps: 2147-2151
    -> ordered by Begin/End snapshot, Alloc (MB) desc
                            Alloc   Used   Freeabl     Max      Hist Max
         PId Category       (MB)    (MB)     (MB)   Alloc (MB) Alloc (MB)
    E     24 PL/SQL             .1      .0                  .1         .1
           7 CKPT --------     1.5      .4       .7        1.5        2.3
             Other              .8                          .8        1.5
             Freeable           .7      .0                  .7
             SQL                .0      .0                  .0         .1
             PL/SQL             .0      .0                  .0         .0
           9 RECO --------     1.2      .5       .6        1.2        1.2
             Freeable           .6      .0                  .6
             Other              .5                          .5         .5
             SQL                .1      .1                  .1         .5
             PL/SQL             .0      .0                  .0         .0
         219  ------------     1.2      .5       .0        1.2        1.2
             Other             1.1                         1.1        1.1
             PL/SQL             .0      .0                  .0         .0
             SQL                .0      .0                  .0         .2
          21  ------------     1.1      .5       .0        1.1        1.1
             Other             1.0                         1.0        1.0
             PL/SQL             .0      .0                  .0         .0
             SQL                .0      .0                  .0         .2
          31  ------------     1.1      .6       .1        1.1        1.1
             Other              .9                          .9         .9
             SQL                .1      .0                  .1         .2
             Freeable           .1      .0                  .1
             PL/SQL             .1      .0                  .1         .1
         205  ------------     1.1      .5       .0        1.1        1.1
             Other             1.0                         1.0        1.0
             PL/SQL             .1      .0                  .1         .1
             SQL                .0      .0                  .0         .1
          27  ------------     1.1      .5       .0        1.1        1.1
             Other             1.0                         1.0        1.0
             PL/SQL             .1      .0                  .1         .1
             SQL                .0      .0                  .0         .1
         158  ------------     1.1      .5       .0        1.1        1.1
             Other             1.0                         1.0        1.0
             PL/SQL             .1      .0                  .1         .1
             SQL                .0      .0                  .0         .1
         172  ------------     1.1      .5       .0        1.1        1.1
             Other             1.0                         1.0        1.0
             PL/SQL             .1      .0                  .1         .1
             SQL                .0      .0                  .0         .1
    Enqueue activity  DB/Inst: apple22A/apple22a  Snaps: 2147-2151
    -> only enqueues with waits are shown
    -> Enqueue stats gathered prior to 10g should not be compared with 10g data
    -> ordered by Wait Time desc, Waits desc
    Enqueue Type (Request Reason)
        Requests    Succ Gets Failed Gets       Waits Wt Time (s)  Av Wt Time(ms)
    TX-Transaction (row lock contention)
         106,475      106,474           0     106,341       20,273         190.64
    TX-Transaction (index contention)
          44,355       44,355           0      44,319        2,784          62.81
    TX-Transaction (allocate ITL entry)
             184          184           0         182            9          46.81
    HW-Segment High Water Mark
           1,975        1,975           0          70            5          66.29
    FB-Format Block
           2,164        2,164           0          50            3          54.60
    TX-Transaction
         394,649      394,668           0          30            0           4.33
    Undo Segment Summary  DB/Inst: apple22A/apple22a  Snaps: 2147-2151
    -> Min/Max TR (mins) - Min and Max Tuned Retention (minutes)
    -> STO - Snapshot Too Old count,  OOS - Out Of Space count
    -> Undo segment block stats:
       uS - unexpired Stolen,   uR - unexpired Released,   uU - unexpired reUsed
       eS - expired   Stolen,   eR - expired   Released,   eU - expired   reUsed
    Undo   Num Undo       Number of  Max Qry     Max Tx Min/Max   STO/  uS/uR/uU/
    TS# Blocks (K)    Transactions  Len (s)      Concy TR (mins) OOS   eS/eR/eU
       1      117.7         322,423       49         73 15/15     0/0   0/0/0/0/0/0
    Undo Segment Stats  DB/Inst: apple22A/apple22a  Snaps: 2147-2151
    -> Most recent 35 Undostat rows, ordered by End Time desc
                    Num Undo    Number of Max Qry  Max Tx Tun Ret STO/  uS/uR/uU/
    End Time          Blocks Transactions Len (s)   Concy  (mins) OOS   eS/eR/eU
    17-Aug 03:40     117,733      322,423      49      73      15 0/0   0/0/0/0/0/0
    Latch Activity  DB/Inst: apple22A/apple22a  Snaps: 2147-2151
    ->"Get Requests", "Pct Get Miss" and "Avg Slps/Miss" are statistics for
      willing-to-wait latch get requests
    ->"NoWait Requests", "Pct NoWait Miss" are for no-wait latch get requests
    ->"Pct Misses" for both should be very close to 0.0
                                               Pct    Avg   Wait                 Pct
                                  Get          Get   Slps   Time       NoWait NoWait
    Latch                       Requests      Miss  /Miss    (s)     Requests   Miss
    Consistent RBA                    3,517    0.0             0            0
    FAL request queue                    11    0.0             0            0
    FAL subheap alocation                11    0.0             0            0
    FIB s.o chain latch                  20    0.0             0            0
    FOB s.o list latch                  361    0.0             0            0
    JS mem alloc latch                    2    0.0             0            0
    JS queue access latch                 2    0.0             0            0
    JS queue state obj latch          3,706    0.0             0            0
    JS slv state obj latch               16    0.0             0            0
    KGX                                   0                    0      353,668    6.5
    KMG MMAN ready and start            636    0.0             0            0
    KMG resize request state             27   33.3    1.0      0            0
    KTF sga latch                         2    0.0             0          165    0.0
    KWQP Prop Status                      4    0.0             0            0
    MQL Tracking Latch                    0                    0           11    0.0
    Memory Management Latch             660    0.2    0.0      0          624    0.0
    OS process                          294    0.0             0            0
    OS process allocation               507    0.0             0            0
    OS process: request allo            333    0.0             0            0
    PL/SQL warning settings         270,940    0.3    0.0      0            0
    SGA IO buffer pool latch          2,654    0.0             0        5,801    0.0
    SQL memory manager latch              4    0.0             0          158    0.0
    SQL memory manager worka         11,158    0.0             0            0
    Shared B-Tree                        29    0.0             0            0
    active checkpoint queue           8,205    0.0             0            0
    active service list               2,335    0.0    0.0      0          174    0.0
    archive control                      13    0.0             0            0
    archive process latch               171    0.0             0            0
    buffer pool                         139    0.0             0            0
    cache buffer handles             46,062    0.1    0.0      0            0
    cache buffers chains        457,192,374    0.2    0.0   1082    3,785,637    0.6
    cache buffers lru chain         447,547    0.5    0.3      8   90,454,746    2.6
    cache table scan latch                0                    0       11,447    0.0
    cas latch                           100    0.0             0            0
    channel handle pool latc            333    0.0             0            0
    channel operations paren          8,286    0.0             0            0
    checkpoint queue latch          199,380    0.0    0.0      0      386,367    0.0
    client/application info           1,208    0.0             0            0
    compile environment latc        791,470    0.0    0.1      1            0
    dml lock allocation           3,552,580    0.5    0.1    117            0
    dummy allocation                    336    0.3    0.0      0            0
    enqueue hash chains           5,288,101    0.3    0.1     45       23,479    0.4
    enqueues                      1,120,394    0.1    0.1      2            0
    event group latch                   239    0.0             0            0
    file cache latch                  2,388    0.0             0            0
    global KZLD latch for me            236    0.0             0            0
    hash table column usage               0                    0        4,564    0.0
    hash table modification              30    0.0             0            0
    job workq parent latch                0                    0            4    0.0
    job_queue_processes para             11    0.0             0            0
    Latch Activity  DB/Inst: apple22A/apple22a  Snaps: 2147-2151
    ->"Get Requests", "Pct Get Miss" and "Avg Slps/Miss" are statistics for
      willing-to-wait latch get requests
    ->"NoWait Requests", "Pct NoWait Miss" are for no-wait latch get requests
    ->"Pct Misses" for both should be very close to 0.0
                                               Pct    Avg   Wait                 Pct
                                  Get          Get   Slps   Time       NoWait NoWait
    Latch                       Requests      Miss  /Miss    (s)     Requests   Miss
    kks stats                           302    0.0             0            0
    ksuosstats global area               58    0.0             0            0
    ktm global data                     270    0.0             0            0
    kwqbsn:qsga                          29    0.0             0            0
    lgwr LWN SCN                      3,520    0.0             0            0
    library cache                19,899,407    0.4    0.0    199       16,683 ######
    library cache load lock           1,030    0.0             0           63    0.0
    library cache lock               17,688    0.2    0.0      0            0
    library cache lock alloc            990    0.0             0            0
    library cache pin            19,007,237    0.2    0.0     35        1,074    0.0
    library cache pin alloca            681    0.0             0            0
    list of block allocation          1,042    0.1    1.0      0            0
    longop free list parent               8    0.0             0           16   12.5
    messages                         38,525    0.0    0.0      0            0
    mostly latch-free SCN         2,543,316    0.1    0.0      0            0
    multiblock read objects          30,207    0.0    1.0      0            0
    ncodef allocation latch               8    0.0             0            0
    object queue header heap             10    0.0             0        1,365    0.0
    object queue header oper      1,198,162    0.1    0.1      0            0
    object stats modificatio            832    0.0             0            0
    parallel query alloc buf             64    0.0             0            0
    parameter table allocati            116    1.7    0.5      0            0
    post/wait queue                  28,580    0.4    0.0      0        8,842    0.0
    process allocation                  333    0.0             0          239    0.0
    process group creation              333    0.0             0            0
    qmn state object latch                1    0.0             0            0
    qmn task queue latch                124    0.0             0            0
    redo allocation                  22,668    2.0    0.2      1    9,366,319    0.5
    redo copy                            13   76.9    1.3      0    9,367,099    0.4
    redo on-disk SCN                 11,212    0.0             0            0
    redo writing                     23,270    0.0    0.0      0            0
    resmgr group change latc            244    0.0             0            0
    resmgr:actses active lis            347    0.0             0            0
    resmgr:actses change gro            238    0.0             0            0
    resmgr:free threads list            335    0.3    0.0      0            0
    resmgr:schema config                 12    0.0             0            0
    rm cas latch                      1,038    0.0             0            0
    row cache objects               464,390    0.0    0.0      0            0
    rules engine rule set st            400    0.0             0            0
    sequence cache                      752    0.0             0            0
    session allocation            1,627,067    0.2    0.0      1            0
    session idle bit              1,875,662    0.0    0.0      0            0
    session state list latch            486    0.0             0            0
    session switching                     8    0.0             0            0
    session timer                       174    0.0             0            0
    shared pool                      58,091    0.3    0.3      1            0
    simulator hash latch         32,009,012    0.0    0.0      0            0
    simulator lru latch          20,996,297    4.9    0.0   1243       15,131    0.2
    slave class                           1    0.0             0            0
    slave class create                    3    0.0             0            0
    Latch Activity  DB/Inst: apple22A/apple22a  Snaps: 2147-2151
    ->"Get Requests", "Pct Get Miss" and "Avg Slps/Miss" are statistics for
      willing-to-wait latch get requests
    ->"NoWait Requests", "Pct NoWait Miss" are for no-wait latch get requests
    ->"Pct Misses" for both should be very close to 0.0
                                               Pct    Avg   Wait                 Pct
                                  Get          Get   Slps   Time       NoWait NoWait
    Latch                       Requests      Miss  /Miss    (s)     Requests   Miss
    sort extent pool                    100    0.0             0            0
    threshold alerts latch               29    0.0             0            0
    transaction allocation              965    0.0             0            0
    transaction branch alloc              8    0.0             0            0
    undo global data             24,845,984    0.2    0.0     20            0
    user lock                           658    4.4    0.9      1            0
    Latch Sleep breakdown  DB/Inst: apple22A/apple22a  Snaps: 2147-2151
    -> ordered by misses desc
                                           Get                                 Spin
    Latch Name                        Requests       Misses      Sleeps        Gets
    simulator lru latch             20,996,297    1,020,829      20,140   1,003,339
    cache buffers chains           457,192,374    1,016,828      24,247     994,418
    library cache                   19,899,407       86,387       3,201      83,529
    undo global data                24,845,984       42,072         497      41,638
    library cache pin               19,007,237       36,024         619      35,469
    dml lock allocation              3,552,580       17,725       1,223      16,696
    enqueue hash chains              5,288,101       14,754       1,086      13,773
    simulator hash latch            32,009,012        7,219          54       7,171
    session allocation               1,627,067        2,489         117       2,385
    cache buffers lru chain            447,547        2,278         583       1,792
    mostly latch-free SCN            2,543,316        1,814          14       1,802
    enqueues                         1,120,394        1,253          89       1,172
    object queue header operat       1,198,162        1,010          52         965
    PL/SQL warning settings            270,940          682           5         677
    redo allocation                     22,668          448          71         389
    session idle bit                 1,875,662          387           8         380
    compile environment latch          791,470          176          12         165
    shared pool                         58,091          171          48         127
    checkpoint queue latch             199,380           33           1          32
    user lock                              658           29          25           5
    redo copy                               13           10          13           0
    KMG resize request state o              27            9           9           0
    parameter table allocation             116            2           1           1
    multiblock read objects             30,207            1           1           0
    list of block allocation             1,042            1           1           0
              -------------------------------------------------------------Edited by: praveenkumaar on Aug 18, 2009 4:07 AM

  • Adding field in standard IDOC Segment E1EDL24

    Hello Friends,
    I have an urgent requirement that I have to extend IDOC segment E1EDL24 with two fields PABNR and LFSNR.
    When I tries to change the segment in WE31, it shows an error message that you can only modify the segments of customer namespace and cannot modify Standard IDOC Segments.
    Can we modify the standard IDOC segments, and if yes, how can we modify the standard IDOC segments. Please clarify.
    Points will be rewarded generously.
    Regards,
    Navin

    Hi Naveen,
    We cannot Modify the Standard segments. But we have to Create a new Segment and Add these fields.
    Then Create an Extended Idoc type
    Implement User Exits in Outbound And Inbound ..
    This is the Complete Steps and Info on this...with an Example...
    Enhancing ALE
    For example, if in an outbound interface you find that the IDOC type does not contain all the data you need to pass to the other system, you can extend the IDOC to accommodate the additional fields and enhance the ALE function modules to populate the fields. Similarly, if in an inbound interface, there is additional data that needs to be posted to the R/3 application, you can extend the IDOC type to have additional fields populated by the external system or translator or the other R/3 system and then enhance the inbound ALE function modules to post the additional data to the R/3 application.
    let us use the SAP Customer Master application as an example. Specifically, letâs focus on the IDOC extension and ALE function module enhancement of IDOC type DEBMAS02 and message type DEBMAS (Customer Master) and the IDOC reduction of message type MATMAS.
    IDOC EXTENSIONS
    Letâs first look at the concept of IDOC extension. SAP delivers Basic IDOC types such as DEBMAS02, MATMAS02, ORDERS02, and WMMBID01. By extending the Basic IDOC type, you are actually creating a new IDOC type. You create a new segment with the additional fields. This new segment has to be associated with one of the existing Basic IDOC segments. Then you create a new extension type, which is associated with the Basic IDOC type. This results in a new IDOC type. In order for ALE function modules to relate to this new IDOC type, the IDOC type is linked to the corresponding message type.
    Note that you should not add fields to existing segments but should create a new segment and associate it with an existing segment. This, in a nutshell, is the process of creating IDOC extensions.
    In our example, the Basic IDOC type DEBMAS02 is used to communicate Customer Master data to the SAP Customer Master application. Even though the application has a screen to enter and store a contact personâs business address (see Figure 1), DEBMAS02 does not have a segment or fields that communicate the contact personâs business address. If your business requires that this business address be communicated to the other system through the ALE interface for Customer Master, then you have to extend the DEBMAS02 IDOC type, and enhance the corresponding ALE function module.
    In DEBMAS02 the contact person fields are present in segment E1KNVKM and the business address of the contact person is stored on the SADR SAP table. You need to create a new segment, Z1SADRX, that is associated with E1KNVKM. This will be done in the process of creating an extension type ZDEBMASX. This extension type will then be associated with a new IDOC type, ZDEBMASZ. IDOC type ZDEBMASZ will be linked to message type DEBMAS for Customer Master. The final step in the IDOC extension process is to check the new objects. This check also verifies the structural integrity of the IDOC type. Letâs look at each of these steps in more detail.
    1. Create an Extension Type and a New Segment.
    Determine the fields on table SADR that you are going to provide for in the new segment Z1SADRX. You need fields for name, street, city, region, and country to give the business address of the contact person. You also need fields for the address number. ADRNR is a field in SAP tables such as SADR that uniquely identifies the address of an entity. This field is cross-referenced from other tables to the SADR table to obtain the full description of the address. Because this is an IDOC type for master data, the first field of the new segment will be MSGFN. The message function field informs the receiving system of the action to be taken for that particular segment. In the code that you write for populating the new segment, the value of the message function is the same as that of the parent segment E1KNVKM. In all, you will have 12 fields in segment Z1SADRX (see Table 1).
    To create an extension type and new segment:
    • Use transaction WE30 or from WEDI go to Development -> IDOC types.
    • Enter ZDEBMASX for Object Name.
    • Choose Extension Type.
    • Click on Create.
    • You will see a pop-up screen. Choose Create New, and enter a description. For version 4.x, enter DEBMAS02 in the Linked Basic Type field. Enter.
    • You will see a screen with ZDEBMASX and its description in the first line. Click on this line, and press Create. For version 4.x, expand the tree of segments, and place the cursor on E1KNVKM.
    • You will see a pop-up screen. Enter E1KNVKM as the reference segment. Enter.
    • For 4.x, press Create after placing the cursor on segment E1KNVKM.
    • You will see a line appear with E1KNVKM hierarchically below ZDEBMASX, with a description "Customer Master contact person (KNVK)."
    • Click on this line and press Create. You will receive a message indicating that the new segment being created will be a child segment of E1KNVKM. Enter. A pop-up box appears for the new segment.
    • Enter Z1SADRX as the segment type, 1 for Minimum, 1 for Maximum. Leave Mandatory segment unchecked. These entries imply that there is only one Z1SADRX segment for every occurrence of the E1KNVKM segment, and also that this segment is not mandatory. Note that if the parent segment is not mandatory, then the child segment should not be mandatory, because this could result in a syntax error during the creation or processing of the IDOC.
    • For 4.x, you must first create the IDOC segment Z1SADRX (Iâll explain why in a moment) from the menu path WEDI -> IDOC -> Development -> IDOC Segment.
    • Click on Segment Editor.
    • On the next screen, click on Create.
    • Enter a development class for the object. Enter.
    • This will take you to the screen for segment definition. Enter a description for the segment. Enter the field name, data element, and the data element documentation name. In most cases, all three fields may have the same values. If you are using a field in the segment that is not present in the ABAP/4 data dictionary, you must first create the domain, data element, field, and appropriate documentation before using it in the new segment.
    • Enter these three columns for all 12 fields. Save.
    • Click on Generate/Activate, F3 to step back.
    • From screen Maintain Segment, go to Segment Type -> Release. A checkbox now appears beside the segment definition Z1SADRX (see Figure 2). Check this box. Save.
    • Save again to store the descriptions of the segment, F3 to step back.
    • Save the extension type.
    It is possible to have several new segments with relevant Basic IDOC type parent segments in a single extension type. However, you can form only one IDOC type based on a single extension type.
    2. Create an IDOC Type.
    The next step is to create an IDOC type by associating the extension type that you created with the Basic IDOC type. This is a simple process:
    • From transaction WE30 or WEDI go to Development -> IDOC Types.
    • Enter ZDEBMASZ for Object Name.
    • Click on IDOC Type.
    • Click on Create.
    • Enter DEBMAS02 for Basic IDOC type.
    • Enter ZDEBMASX for extension type.
    • Enter a description.
    • Enter.
    • You will see a display of the composite IDOC type with all segments, including Z1SADRX (see Figure 3).
    It is possible to associate only one extension type with a Basic IDOC type for a given IDOC type. However, you can have multiple new segments in an extension type.
    3. Link IDOC Type to Message Type.
    The next step is to link the new IDOC type to its corresponding message type. This is important, because this relationship is referenced in the partner profile parameters where you specify the message type and IDOC type to be used for that particular representative system. To link the message type:
    • Use transaction WE82, or from WE30, go to Environment -> IDOC Type / Message Type, or from WEDI go to Development -> IDOC Type -> Environment Î IDOC Type / Message Type.
    • Click on Display <-> Change.
    • Click on New Entries.
    • Enter DEBMAS for message type.
    • Enter DEBMAS02 for Basic IDOC type.
    • Enter ZDEBMASX for extension type.
    • Enter your SAP R/3 release number for Release.
    • Save.
    This data is stored on the EDIMSG table and is accessed by several ALE processes to relate the message type to the IDOC type.
    4. Check the IDOC Type.
    Before checking the IDOC type for consistency, it is important to perform another step that releases the extension type to the IDOC type:
    • From WEDI go to Development -> IDOC Types -> Extras -> Release Type, or from transaction WE30 go to Extras -> Release Type.
    • For the Object Name ZDEBMASX and radio button Extension Type, click Yes.
    • The extension type has now been "released."
    You canât edit the extension type once itâs released. To cancel the release for further editing or deactivation, go to WE30 Î Extras Î Cancel release. The final step in the IDOC extension process is checking the validity of the IDOC type:
    • From transaction WE30 or WEDI go to Development -> IDOC types.
    • Enter ZDEBMASX for Object name.
    • Click on Extension Type.
    • From the Development Object menu select Check.
    • Repeat the operation for IDOC type ZDEBMASZ.
    • A check log will be generated for each run with details of correctness or errors (see Figure 4).
    In some situations it is possible to receive errors during the check process, especially segment length errors. The incorrect IDOC segment can be repaired and corrected by executing program RSEREPSG. This program checks the formal consistency and repairs incorrect segments. In test mode it will generate a log of formal correctness for the specified segment only. For the program to repair segments in normal mode, the underlying IDOC structures (DDIC structures) must be active. This program rectifies the lengths of the DDIC structures and not the fields themselves. RSEREPSG can also be used to change the person responsible for the object and the release flag.
    Menu paths may vary slightly depending on the release/version of SAP R/3, but the procedures and the principles are the same.
    ALE FUNCTION MODULE ENHANCEMENTS
    Having extended the IDOC type to contain additional fields for an inbound or outbound application, you now want to enhance ALE function modules for populating the additional segment on the outbound or applying the additional segment data on the inbound application.
    The core working code for ALE processes for a given application area is always encapsulated in ABAP/4 function modules. These function modules are associated with such control information as message types and process codes. So the ALE process checks this control information and derives the name of the function module to invoke for that particular IDOC processing from certain database tables. These function modules contain objects known as customer functions, which can be considered SAP Enhanced user exits. A function module is called at a particular point during the processing of the main program or function module, and it can be used to influence data processing at that point by adding code to the customer function. The customer function behaves like a normal function module and has import and export parameters, tables (internal tables) statement, and exception processing. Unlike a conventional user exit, customer functions give you the ability to modify only data available to you by the function moduleâs parameters and internal tables. While most ALE/EDI function modules are supported by customer functions, there are ALE/EDI processes that still use conventional user exits. There are a few ways to determine which function module to enhance for a given message type/process code:
    • For master data distribution, from SALE go to Extensions -> Master data distribution -> Setup additional data for message types. Search for message type DEBMAS in this example. You see an entry for DEBMAS associated with function module MASTERIDOC_CREATE_SMD_DEBMAS. This data is stored on table TBDME. The function module names for all master data message types follow this pattern: MASTERIDOC_CREATE_SMD_messagetype. This function module calls another function module of name MASTERIDOC_CREATE_DEBMAS or MASTERIDOC_CREATE_messagetype. Search for the words customer function, and you find several hits that can be used to add code to the function module.
    • From WEDI got to Control -> Inbound process codes -> Inbound with ALE service -> Processing by function module (transaction WE42), or from WEDI go to Control -> Outbound process codes -> Outbound with ALE service -> With function module (transaction WE41). There will be function modules associated with the process codes. For inbound, the function modules usually follow this pattern: IDOC_INPUT_messagetype: for example, IDOC_INPUT_CHRMAS for inbound characteristics master.
    • Use transaction WE57 or from WEDI go to Development -> Message/Application Object. The entries list the function module, Business Object, message type, and IDOC type that are used for inbound ALE/EDI interfaces.
    Customer functions are not specific only to ALE and EDI but also to all programs/modules in SAP R/3. Customer function is a SAP enhancement component; the other two types are menu and screen enhancements.
    All customer function exits are maintained in SAP enhancements and are found by using transaction SMOD. After executing transaction SMOD, pull down (F4) on the enhancement name field, and execute again. This provides you with a list of all SAP enhancements available. SAP enhancements are grouped by development class pertaining to an application area. Choose Application development R/3 SD master data distribution for development class VSV to lead to a screen that lists VSV00001 as an enhancement (see Figure 5). Press Component +/- to display its function exit components. There are four possible components listed, all of which are function exits (and are function modules) that are called from the ALE function modules in the form Call Customer Function Î001â. This is a special occurrence of the ABAP statement Call. Go to item Exit_SAPLVV01_ 001, which you need to enhance for the Customer Master outbound example of an IDOC extension. In the ALE-function module MASTERIDOC_CREATE_DEBMAS, the statement CALL Customer Function 001 is translated in the background to call component EXIT_SAPLVV01_001. Although this function exit can be edited using transaction SE37, you will use a simpler approach.
    When you use SAP enhancements and their components, you manage them with an SAP object known as a project, which is like an envelope containing the selected enhancements and their components. A project can be used to control the execution of components and to transport them to other clients and instances in SAP. Basically, the process involves creating a project, including enhancements and components that are to be enhanced, editing the components, and then activating the project. The following process creates a project for our example Customer Master IDOC extension:
    • Execute transaction CMOD.
    • Enter name of project, say CSTMAST1.
    • Click on Create.
    • Enter a description of the project.
    • Save.
    • Click on SAP Enhancements.
    • Enter VSV00001 for Enhancement.
    • Save.
    Once youâve created the project, edit the function exit components and activate the project. Remember that the code in the function exit enhancement will execute only if the project is activated. In fact, this is a convenient SAP enhancements feature, whereby the work in progress (developing code in the customer function) will not affect users of that application. When the code is completed, the project can be activated so the enhanced functionality takes effect. It can also be deactivated for maintenance.
    As mentioned earlier, customer functions (function exits) are embedded in ALE function modules and can be used to influence the creation and modification of IDOC data on an outbound application or to post additional or modified IDOC data to an inbound R/3 application. Function exits are similar to regular function modules, with import/export parameters, tables (internal tables), and exceptions.
    The two important factors to consider while developing the customer function are:
    1. The point in the ALE function module where the function exit occurs
    2. The data made available by the customer function that can be modified or posted to the R/3 application, based on the direction.
    Because some function modules have several customer functions, it is critical to choose the function exit best suited for that particular enhancement. Do not attempt to perform activities that the function exit is not designed for. The importance of this point is illustrated by the following description of enhancing function modules for outbound and inbound ALE interfaces.
    Outbound interfaces. In an outbound ALE interface you use function exits (customer functions) to populate additional segments created by an IDOC extension or to modify the existing IDOC data segments as per business requirements. Previously, you identified that enhancement VSV00001 has a component EXIT_SAPLVV01_001 (function exit), which can be used for populating the additional data segment Z1SADRX that you created in the IDOC extension ZDEBMASX (IDOC type ZDEBMASZ, based on Basic IDOC type DEBMAS02). You also learned that the ALE function module that calls this function exit is MASTERIDOC_CREATE_DEBMAS, which has a statement Call Customer Function 001.
    Browse the function module MASTERIDOC_CREATE_DEBMAS using transaction SE37. You will find that this customer function is invoked for every segment of IDOC type DEBMAS02. In fact, the function exit is called soon after the creation of an existing segment has been populated with data and appended to the IDOC data table (internal table). Also, the function exit is exporting the message type, IDOC type, and the segment name and is importing the IDOC extension type. It is also passing the IDOC data internal table. This indicates that the ALE function module is allowing you to populate additional segments for every existing segment and modify the existing segmentâs data.
    Letâs write ABAP/4 code to accomplish the task of populating IDOC segment Z1SADRX with a contact personâs business address:
    • From SE37, display function module MASTERIDOC_CREATE_ DEBMAS.
    • Find Customer Function 001.
    • Double-click on 001.
    • The function EXIT_SAPLVV01_001 will be displayed.
    • Double-click on INCLUDE ZXVSVU01.
    • You will be asked to create a new include object. Proceed as desired.
    • Enter code (as in Listing 1).
    • Be sure to perform a main program check (Function Module -> Check -> main program) and extended program check (Function module -> Check -> Extended check).
    Now that you have extended the IDOC and enhanced the ALE function module based on the requirements for the contact personâs business address on the Customer Master, letâs test the interface. You should create a logical system and define a port for this interface. You should also configure the Customer Distribution Model to indicate that message type DEBMAS is being distributed to this logical system. The only difference in configuration between a regular outbound ALE interface and an enhanced one is the partner profile definition. While maintaining the outbound parameters of the partner profile, make sure the IDOC type is ZDEBMASZ. The fields for Basic IDOC type and extension type are automatically populated with DEBMAS02 and ZDEBMASX, respectively.
    To maintain the contact personâs business address of a customer:
    • Use transaction BD12 or from BALE go to Master Data ->Customer -> Send and send that Customer Master record by executing the transaction after filling in the relevant fields such as customer number, message type, and logical system.
    • Use transaction WE02 or WE05 to verify the IDOC created. You should see the new segment Z1SADRX populated with the correct data.
    With SAP releases below 4.5B, you cannot capture changes to business address through change pointers because a change document object is not available for capturing business address changes, and also earlier releases have not been configured to write change documents for a contact personâs business address. If you would like this functionality, you can either create change document objects, generate function modules to create change documents, and perform ALE configuration to tie it in, or make a cosmetic change to the contact person screen data while changing the contact personâs business address so that it gets captured as a change to the Customer Master. Subsequently, the ALE enhancement that you performed captures the contact personâs business address.
    Inbound interfaces. The process for enhancing inbound ALE interfaces is similar for outbound, with a few exceptions; specifically in the coding of customer functions (function exits) for the ALE/EDI function modules.
    The first step is to create an IDOC extension for the specific Basic IDOC type by adding new segments at the appropriate hierarchy level: that is, associated to the relevant existing segment. Populate the data fields on the new segments with application data by the translator or external system/program before importing them into the R/3 System. Then, find the ALE function module that is invoked by the inbound processing. By browsing through the code or reading the documentation on the function exit enhancements using the SMOD transaction, identify the function exit in which you should place your code. The technique used in the code to post the additional or modified IDOC data to the application can vary based on the application rules and requirements, the data available at that point in processing, and the application function modules available to update the application tables. It is important to search first for application modules that process the data and see if they can be called within the function exit. If the additional data in the extended segments in specific to a custom table or resides in nonkey fields of a single or small set of tables, you may be able to update it directly by SQL statements in the function exit. This approach should be carefully evaluated and is certainly not highly recommended.
    Another option is to use Call Transaction from within the function exit to process the additional data. For example, in the case of message type WMMBXY for inbound goods movements from a warehouse management system, the standard interface creates batches for materials, but does not update its characteristics. In such a case, you can use Call Transaction MSC1 to create the batch and assign characteristic values to it from within the function exit provided.
    Error handling is a very important consideration when making enhancements to inbound ALE/EDI objects. In ALE and EDI inbound processing, workflow is used for handling errors at different levels such as technical and application. If workflow has been configured for the interface, the error messages and workflow items flow to the inbox of the named recipient(s).
    It is also critical to enhance the workflow that handles notifications of the inbound ALE/EDI process. In most scenarios this is not a very difficult task because SAP lets you influence the workflow parameters and messages in function exits (customer functions). You typically do this using flags and message codes to trigger certain workflow actions. If you conform to the status codes and flags stipulated for workflow processing, the enhancement could be error-free and seamless. In the case of an inbound IDOC with an extension, you should populate the EDIDC fields IDOCTYP (new IDOC type) and CIMTYP (extension type) accordingly.
    Reward if Helpful

Maybe you are looking for