Logical units in DB-Tablespace,extent, segments, data blocks

I understand what are tablespaes,Segments,Extents, data blocks.But i want to know why do we have all these logical seggregations.Does DBA create all these while creating tablespaces?
Could some one plz explain me the exact concept behind having all these?

user11365275 wrote:
I understand what are tablespaes,Segments,Extents, data blocks.But i want to know why do we have all these logical seggregations.Does DBA create all these while creating tablespaces?
Could some one plz explain me the exact concept behind having all these?You should check and read the link that Helios has given. The DBA is only going to create tablespaces with datafiles added to them. The rest of the things are going to come into as and when the objects are going to get created, either by the DBA or by the end users. To answer why, this is the why oracle lets the dba manage the granularity within the datafile. These are all logical constructs which means, their existence is only within the oracle's own views . In real, its just bunch of files allocating space on the physical hard drive.
Aman....

Similar Messages

Segments, extents and data blocks

I'm somewhat green when it comes to Oracle and databases in general, so bare with me. I bought the OCP Exam Guide to try and learn as much as I can. I'm at the chapter about segments, extents and data blocks and I'm having a bit of trouble grasping the conecpts of these. Are these logical? Does anyone have time for quick overview?
Thank you!

Ignoring the O/S, the basic storage unit in Oracle is a block (db_block). You define the size of the block with the db_block_size parameter, and it is effectively fixed at database creation. You can have tablespaces with a different block size from the database default, but we won't go there for now. A db_block is not the sme as an O/S block, so in that sense it is a logical unit.
In Oracle, a segment is anything that takes disc space, generally speaking, a table or an index. Every segment is stored in a tablespace. A segment can only be in one tablespace, but a tablespace can hold many segments. A tablespace gets its space from a data file (an O/S file). Each data file belongs to one tablespace, but a tablespace can have multiple data files.
Each segment is made up a a number of extents. The are the units of space that are allocated to the segment as it needs space. The size of each extent is controlled by either the INITIAL and NEXT parameters in CREATE TABLESPACE or in one of the CREATE <segment> commands. If you are using locally managed tablespaces, the tablespace parameters define the extent sizes. Each extent belongs to only one segment, but a segment can have many extents. Although the extent sizes are defined in bytes, they must be a multiple of the block size.So, if you have an 8K block size, you cannot have a 12K extent size.
So:
An extent is made up of one or more (contiginous) blocks within a data file.
A segment is made up of one or more (possibly non-contiginous) extents possibly in multiple data files.
Note that the blocks in an extent must be contiginous, but that is a logical concept within Oracle, since Oracle has no way of knowing how and where the O/S has actually allocated the physical space, it just has an internal map of the file space allocated by the O/S.
HTH
John

What is the difference between a tablespace, a segment and an extent ?

What is the difference between a tablespace, a segment and an extent ? Please explain in layman terms since I'm a total newbie to Oracle.
Regards
Gony

Hi,
These are logical structure of database
1. Tablespace : A database is divided into logical storage units called tablespaces, which group related logical structures together. For example, tablespaces commonly group together all application objects to simplify some administrative operations.
2.Segments
Above extents, the level of logical database storage is a segment. A segment is a set of extents allocated for a certain logical structure. The following table describes the different types of segments.
Segment Description
Data segment
Each nonclustered table has a data segment. All table data is stored in the extents of the data segment.
For a partitioned table, each partition has a data segment.
Each cluster has a data segment. The data of every table in the cluster is stored in the cluster's data segment.
Index segment
Each index has an index segment that stores all of its data.
For a partitioned index, each partition has an index segment.
Temporary segment
Temporary segments are created by Oracle when a SQL statement needs a temporary work area to complete execution. When the statement finishes execution, the extents in the temporary segment are returned to the system for future use.
Rollback segment
If you are operating in automatic undo management mode, then the database server manages undo space using tablespaces. Oracle Corporation recommends that you use "Automatic Undo Management" management.
3. Extents
The next level of logical database space is an extent. An extent is a specific number of contiguous data blocks, obtained in a single allocation, used to store a specific type of information.

Data Block, Extents, and Segments in Datafiles

I'm trying to understand the relationship of Data Blocks, Extents, and Segments in Datafiles. What is the simpliest explanation for their relationships.

Hi,
Look at this (might be more readable if you paste it somewhere and use a font with fixed width):
SQL>CONNECT SYSTEM/MANAGER
ConnectÚ.
SQL> CREATE TABLE MyTable
2 (
3 CH1 VARCHAR2(10),
4 CH2 VARCHAR2(10)
5 ) TABLESPACE TOOLS;
Table crÚÚe.
SQL>SELECT * FROM DBA_SEGMENTS WHERE SEGMENT_NAME='MYTABLE';
OWNER SEGMENT_NAME PARTITION_NAME SEGMENT_TYPE TABLESPACE_NAME HEADER_FILE HEADER_BLOCK BYTES BLOCKS EXTENTS INITIAL_EXTENT NEXT_EXTENT MIN_EXTENTS MAX_EXTENTS PCT_INCREASE FREELISTS FREELIST_GROUPS RELATIVE_FNO BUFFER_
SYSTEM MYTABLE TABLE TOOLS 7 1555 65536 16 1 65536 1 2147483645 7 DEFAULT
SQL> SELECT * FROM DBA_EXTENTS WHERE SEGMENT_NAME='MYTABLE';
OWNER SEGMENT_NAME PARTITION_NAME SEGMENT_TYPE TABLESPACE_NAME EXTENT_ID FILE_ID BLOCK_ID BYTES BLOCKS RELATIVE_FNO
SYSTEM MYTABLE TABLE TOOLS 0 7 1553 65536 16 7
SQL> -- Give it another extent
SQL> ALTER TABLE MyTable ALLOCATE EXTENT;
Table modifiÚe.
SQL> SELECT * FROM DBA_EXTENTS WHERE SEGMENT_NAME='MYTABLE';
OWNER SEGMENT_NAME PARTITION_NAME SEGMENT_TYPE TABLESPACE_NAME EXTENT_ID FILE_ID BLOCK_ID BYTES BLOCKS RELATIVE_FNO
SYSTEM MYTABLE TABLE TOOLS 0 7 1553 65536 16 7
SYSTEM MYTABLE TABLE TOOLS 1 7 1569 65536 16 7
SQL> -- Note that in this particular case, Both extents are on the same datafile (7), and if you add the block_id (first block in the extent) of the extent 0 (first one) to the number
SQL> -- of blocks in the extent (16) = 1553 + 16 = 1569 = BLOCK_ID of the second extent (they are physically side by side)
SQL> -- THIS IS NOT ALWAYS TRUE, AND GENERALLY FALSE!
SQL>
SQL> -- Let's dump the first block and see what's in:
SQL> ALTER SYSTEM DUMP DATAFILE 7 BLOCK 1553;
SystÞme modifiÚ.
SQL> -- Now edit the trace file
/* Content:
Start dump data blocks tsn: 7 file#: 7 minblk 1553 maxblk 1553
buffer tsn: 7 rdba: 0x01c00611 (7/1553)
scn: 0x0000.0007b1fa seq: 0x02 flg: 0x00 tail: 0xb1fa2002
frmt: 0x02 chkval: 0x0000 type: 0x20=FIRST LEVEL BITMAP BLOCK
Dump of First Level Bitmap Block
nbits : 4 nranges: 1 parent dba: 0x01c00612 poffset: 0
unformatted: 13 total: 16 first useful block: 3
owning instance : 1
instance ownership changed at
Last successful Search
Freeness Status: nf1 0 nf2 0 nf3 0 nf4 0
Extent Map Block Offset: 4294967295
First free datablock : 3
Bitmap block lock opcode 0
Locker xid: : 0x0000.000.00000000
Highwater:: 0x01c00614 ext#: 0 blk#: 3 ext size: 16
#blocks in seg. hdr's freelists: 0
#blocks below: 0
mapblk 0x00000000 offset: 0
HWM Flag: HWM Set
DBA Ranges :
0x01c00611 Length: 16 Offset: 0
0:Metadata 1:Metadata 2:Metadata 3:unformatted
4:unformatted 5:unformatted 6:unformatted 7:unformatted
8:unformatted 9:unformatted 10:unformatted 11:unformatted
12:unformatted 13:unformatted 14:unformatted 15:unformatted
End dump data blocks tsn: 7 file#: 7 minblk 1553 maxblk 1553
SQL> -- Now add 2 lines
SQL> INSERT INTO MYTABLE VALUES ('ABC','123');
1 ligne crÚÚe.
SQL> COMMIT;
Validation effectuÚe.
SQL> INSERT INTO MYTABLE VALUES ('DEF','456');
1 ligne crÚÚe.
SQL> COMMIT;
Validation effectuÚe.
SQL> -- And get the ROWID (absolute line physical position) of these lines
SQL> SELECT ROWID FROM MYTABLE;
ROWID
AAAHotAAHAAAAYfAAA
AAAHotAAHAAAAYfAAB
SQL> -- Absolute file number of these 2 lines:
SQL> SELECT DBMS_ROWID.ROWID_TO_ABSOLUTE_FNO('AAAHotAAHAAAAYfAAA','SYSTEM','MYTABLE') FROM DUAL;
DBMS_ROWID.ROWID_TO_ABSOLUTE_FNO('AAAHOTAAHAAAAYFAAA','SYSTEM','MYTABLE')
7
SQL> SELECT DBMS_ROWID.ROWID_TO_ABSOLUTE_FNO('AAAHotAAHAAAAYfAAB','SYSTEM','MYTABLE') FROM DUAL;
DBMS_ROWID.ROWID_TO_ABSOLUTE_FNO('AAAHOTAAHAAAAYFAAB','SYSTEM','MYTABLE')
7
SQL> -- Both in file 7: no surprise, in the extent.
SQL> -- Let's be curious and look up the block id:
SQL> SELECT DBMS_ROWID.ROWID_BLOCK_NUMBER('AAAHotAAHAAAAYfAAA') FROM DUAL;
DBMS_ROWID.ROWID_BLOCK_NUMBER('AAAHOTAAHAAAAYFAAA')
1567
SQL> SELECT DBMS_ROWID.ROWID_BLOCK_NUMBER('AAAHotAAHAAAAYfAAB') FROM DUAL;
DBMS_ROWID.ROWID_BLOCK_NUMBER('AAAHOTAAHAAAAYFAAB')
1567
SQL> -- Both lines are in block number 1567.. look again into the dump from block 1553 (First free datablock : 3)
SQL> -- Dump the block:
SQL> ALTER SYSTEM DUMP DATAFILE 7 BLOCK 1567;
SystÞme modifiÚ.
SQL>
/* Content:
Start dump data blocks tsn: 7 file#: 7 minblk 1567 maxblk 1567
buffer tsn: 7 rdba: 0x01c0061f (7/1567)
scn: 0x0000.0007b2fd seq: 0x01 flg: 0x02 tail: 0xb2fd0601
frmt: 0x02 chkval: 0x0000 type: 0x06=trans data
Block header dump: 0x01c0061f
Object id on Block? Y
seg/obj: 0x7a2d csc: 0x00.7b2f5 itc: 2 flg: E typ: 1 - DATA <--------- Here is the objet ID. 0x7a2d = 31227 (check just below block dump)
brn: 0 bdba: 0x1c00611 ver: 0x01
inc: 0 exflg: 0
Itl Xid Uba Flag Lck Scn/Fsc
0x01 0x0006.003.000002f8 0x008000b7.0081.06 --U- 1 fsc 0x0000.0007b2f9
0x02 0x0005.000.000002fd 0x00800099.008f.16 --U- 1 fsc 0x0000.0007b2fd
data_block_dump,data header at 0x2ff1064
===============
tsiz: 0xf98
hsiz: 0x16
pbl: 0x02ff1064
bdba: 0x01c0061f
76543210
flag=--------
ntab=1
nrow=2 <--------- 2 Lines in the block
frre=-1
fsbo=0x16
fseo=0xf82
avsp=0xf6c
tosp=0xf6c
0xe:pti[0] nrow=2 offs=0
0x12:pri[0] offs=0xf8d
0x14:pri[1] offs=0xf82
block_row_dump:
tab 0, row 0, @0xf8d
tl: 11 fb: H-FL lb: 0x1 cc: 2 <--------- First line header
col 0: [ 3] 41 42 43 <--------- Here is 'ABC'
col 1: [ 3] 31 32 33 <--------- Here is '123'
tab 0, row 1, @0xf82
tl: 11 fb: H-FL lb: 0x2 cc: 2 <--------- Second line header
col 0: [ 3] 44 45 46 <--------- Here is 'DEF'
col 1: [ 3] 34 35 36 <--------- Here is '456'
end_of_block_dump
End dump data blocks tsn: 7 file#: 7 minblk 1567 maxblk 1567
SQL> SELECT OBJECT_ID FROM DBA_OBJECTS WHERE OBJECT_NAME='MYTABLE';
OBJECT_ID
31277
Sincerely hope this'll help you understand.
Regards,
Yoann.

Moving Tablespaces and other data-Objects to another HD

Hi,
XE is running on Win XP Pro SP2 here. It installs the datafiles on C:\ too. That's no proper solution because system loss could cause data loss in a bad crash.
Otherwise in managed enviroments often the sytemdrive will be autmatically cleaned for new desktop solutions.
Is there some experience about moving the tablespaces /moving the datafiles to another HD/Partition?
Doing this on 10g with EMGC is an easy job.
But how does this work on XE?
thx for respone
regards
Franz

You can not move tablespaces. They are logical units that do not have a location. The required space allocation for a tabelespace is through one or more datafiles.
There is no problem moving data files to another drive. Effectively you
1) shutdown the database
2) copy the data file to the new location
3) Update (not edit) the control files to point to the new data file.
Step 3 is done by bringing up the database into 'control files are available and read into memory, but data files are not available' (the 'Mount' state) and issuing the ALTER DATABASE RENAME FILE ... command.
Details, with examples in the 10gR2 DBA manual http://download.oracle.com/docs/cd/B19306_01/server.102/b14231/dfiles.htm#i1106090, at Chapter 9 in the Renaming and Relocating Datafiles section.
Full command syntax in the SQL Reference manual http://download.oracle.com/docs/cd/B19306_01/server.102/b14200/statements_1004.htm#i2079942 in the ALTER DATABASE section.

Logic issues for manipulation of internal table data

Hi,
I am having a issue with logic of one program.
In the XVBAP internal table of SO User Exit.
We will have fields like
UPDKZ, POSNR, UEPOS, ZZECD[Z-Field] etc.
Above fields are related to logic.
1. Now my first point is:
We need to capture Records where UPDKZ='D' and ZZECD[Z-Field] is populated.
For this we will write code as below:
LOOP AT XVBAP WHERE UPDKZ EQ C_D AND
 ZZECD NE SPACE.
Here we will store all fields in I_XVBAP I.Table
ENDLOOP.
Supoose we have retrieved records as below:
VBELN, UPDKZ, POSNR, UEPOS, ZZECD
100 D 000040 000030 Text1
100 D 000050 000020 Text2
100 D 000060 000000 Text3
2. My second point here is:
For Every Item[POSNR] we need to get the Higher level item from UEPOS field, If the Higher level Item also has UPDKZ = D, then move the base unit and all its components into an internal table. continue this process till UEPOS for POSNR is 000000 but High item should have UPDKZ = 'D', not only this all items in this chain should have UPDKZ = 'D'.
Ex:
Suppose for item 000050 UEPOS is 000020 then goto XVBAP with POSNR = UEPOS[000020] and UPDKZ = 'D' if yes and then pick up UEPOS for 000020 item and continue this process till UEPOS becomes 000000 and UPDKZ = 'D'.
Here from Low level to High level all the chain items should have UPDKZ = 'D'. Then only write all items into Final Internal table.
Need to do this process for all above rec's [40,50,60 - POSNR].
Can anybody provide me the logic for the above scenario.
Thanks in advance.
Thanks and Regards,
Deep

Hi Anurag,
Your assumption is wrong.
See first when we get into our logic we will get XVBAP data as below:
VBELN, POSNR, UEPOS, UPDKZ, ZZECD
100, 10, 00, D, Text1
100, 20, 00, , Text2
100, 30, 20, D, Text3
100, 40, 30, D, Text4
100, 50, 00, , Text5
100, 60, 00, D, Text6
100, 70, 60, D, Text7
After we run first point we will get data as:
Here logic is pick up data where UPDKZ = D and ZZECD NE SPACE.
VBELN, POSNR, UEPOS, UPDKZ, ZZECD
100, 10, 00, D, Text1
100, 30, 20, D, Text3
100, 40, 30, D, Text4
100, 60, 00, D, Text6
100, 70, 60, D, Text7
Then we will goto second point:
Here we need to look into 3 things totally in 2nd point:
1. In loop Select the record which has UEPOS EQ space, UPDKZ = D and POSNR should not be UEPOS for any other record from above data from 1st point.
100, 10, 00, D, Text1
will be selected into final internal table as per this point.
2. If for a POSNR value UEPOS NE SPACE, UPDKZ = D then goto UEPOS's POSNR in high level check there if UPDKZ = D and then wether UEPOS is ZERO (or) contains any value.
If any value is there repeat the process till UEPOS become ZERO. Then for that final higher level item check UPDKZ value if it has value as 'D', If has then write all those records from low item to high item into final internal table.
100, 60, 00, D, Text6
100, 70, 60, D, Text7
In above for Item 70[POSNR] we have UEPOS as 60 and UPDKZ as D. then we will goto UEPOS's POSNR, Now POSNR is 60 then check it's UEPOS it is ZERO so check UPDKZ because it is D write both items 60, 70 into final internal table.
2. If for a POSNR value UEPOS NE SPACE, UPDKZ = D then goto UEPOS's POSNR in high level check there if UPDKZ = D and then wether UEPOS is ZERO (or) contains any value.
If any value is there repeat the process till UEPOS become ZERO. Then for that final higher level item check UPDKZ value if it has value as 'D', If it does not have UPDKZ as 'D' then don't write any item from low to high into final internal table.
If we take the scenario of below rows:
100, 20, 00, , Text2
100, 30, 20, D, Text3
100, 40, 30, D, Text4
POSNR-40 has UEPOS-30 & UPDKZ = D then UEPOS's POSNR-30 has UEPOS-20 and UPDKZ-D then UEPOS POSNR-20 has UEPOS as 00 then stop here and see UPDKZ which is ZERO so don't consider items 20,30,40 into final i.table.
In the above chain in any record UPDKZ is not 'D' then skip the process anddon't write the records into final internal table.
Final output will come as:
100, 10, 00, D, Text1
100, 60, 00, D, Text6
100, 70, 60, D, Text7
Thanks for all your efforts.
Thanks,
Deep

What is luw (logical unit of work)

pls tell me what is luw (logical unit of work)
what r the types of luw .
2 what ispurpose of code inspector and extended program check
pls expalin the diffrence b/w those two
3what are the candidate keys in db tables
4 what is the difference b/w occurs 1 and occurs 2 clauses
data : begin of itab occurs 0 .
data : itab type standard table of structure type initial size 1 with header line
pls tell diffrence between theese two statements
5can u pls tell what is the client in sap
pls tell answers to questions
pls dont give any websites addresses to see answers
6 what is the transaction from database point of view
7 what is the variant in alv reports
how do we use reuse_alv_grid_variant_get fun module in alvs

hi,
this gives complete idea
SAP LUW
Since, as a rule, an application program is processed by several work processes in succession, and every change of the work process is linked with an implicit database commit , an application program is not automatically linked with a single database LUW. This applies in particular to dialog-oriented applications, in which one database LUW is assigned to one dialog step.
To ensure the data consistency of application programs that are executed across different work processes, the application statements are not directly executed in an SAP LUW, rather, are first registered and then executed by a single work process, that is, in a single database LUW.
Two techniques are available for bundling the change statements in a database LUW:
Bundling via function modules (update)
Through the statement CALL FUNCTION...IN UPDATE TASK, an update function module is registered for subsequent execution in an update work process.
Bundling via function modules (transactional RFC)
Through the statement CALL FUNCTION... IN BACKGROUND TASK DESTINATION, a remote- compatible function module is registered for subsequent asynchronous execution via the RFC interface (transactional RFC ).
Bundling via subprograms
Through the statement PERFORM ... ON COMMIT, a subprogram is registered for subsequent execution in a different work process.
Statements for SAP LUWs
A SAP LUW is controlled via the Open SQL statements COMMIT WORK, ROLLBACK WORK and SET UPDATE TASK LOCAL.
Note
A function module can be classified either as an update function module or remote-compatible, but not both at the same time. The update helps realize SAP LUWs within an SAP System, while the transactional RFC creates LUWs in distributed systems.
COMMIT WORK
Variants:
1. COMMIT WORK [AND WAIT].
2. COMMIT CONNECTION con.
Effect
Terminates an SAP LUW and stores the changes.
Variant 1
COMMIT WORK [AND WAIT].
Effect
The statement COMMIT WORK completes the current SAP LUW and opens a new one, storing all change requests for the currenta SAP LUW in the process. In this case, COMMIT WORK performs the following actions:
It executes all subroutines registered using PERFORM ON COMMIT.
It triggers an internal event in Object Services that ensures the registration of changes in persistent objects as the last update function module, as well as the subsequent initialization of persistent object attributes.
It initiates the processing of all registered update function modules in the update work process.
This executes all high-priority update function modules registered using CALL FUNCTION ... IN UPDATE TASK in the order of their registration and in a common database LUW. If you do not specify the addition AND WAIT, the program does not wait until the update work process has executed it (asynchronous updating). If you specify the addition AND WAIT, however, program processing after COMMIT WORK will not continue until the update work process has executed the high-priority update function modules (synchronous updating).
If all high-priority update function modules are completed successfully, the statement executes the low-priority update function modules together in a common database LUW.
In parallel, it also executes the individual function modules registered using CALL FUNCTION ... IN BACKGROUND TASK DESTINATION in a separate database LUW for each destination.
It handles all SAP locks set in the current program according to the value of the formal parameter _SCOPE of the corresponding lock function modules.
It triggers a database commit that also terminates the current database LUW.
The completion of statement COMMIT WORK triggers the event TRANSACTION_FINISHED of the system class CL_SYSTEM_TRANSACTION_STATE, where the parameter KIND has the value of the constant CL_SYSTEM_TRANSACTION_STATE=>COMMIT_WORK.
If the statement COMMIT WORK is executed by calling special programs, be aware of the following:
In a program executed using batch input, or if you have called the program using the USING addition of the statement CALL TRANSACTION, COMMIT WORK terminates the batch input processing when using the corresponding settings.
In a program called using CALL DIALOG, COMMIT WORK initiates the processing of subroutines or updated function modules registered using PERFORM ... ON COMMIT and CALL FUNCTION ... IN UPDATE TASK. Therefore, it does not complete the current SAP LUW. The SAP LUW cannot be completed until you execute the COMMIT WORK statement in the calling program.
You cannot execute the COMMIT WORK statement during the updating procedure or during the execution of subroutines registered using PERFORM ... ON {COMMIT|ROLLBACK}.
System fields
sy-subrc Meaning
0 You have specified the AND WAIT addition, and the updating of the update function modules was successful.
4 You have specified the AND WAIT addition, and the updating of the update function modules was not successful.
The COMMIT WORK statement always sets sy-subrc to 0 if the AND WAIT addition is not specified.
Note
The COMMIT WORK statement closes all database cursors . Open SQL statements that access a database cursor later ( SELECT loop and FETCH) raise an exception that cannot be handled.
Variant 2
COMMIT CONNECTION con.
Note
This statement is for internal use only.
It cannot be used in application programs.
Effect
The COMMIT command is not executed on the standard database, but only on the secondary database connection specified by con. con is the name of the database connection as it was specified in the table DBCON in the column CON_NAME. The database connection con can also be specified dynamically in the form (source_text) - the source_text field contains the name of the database connection. The source_text field must be of the type C or STRING.
On the specified secondary database connection, the database commit:
Closes all open database cursors (OPEN CURSOR)
Releases all database locks
Note
Note that the COMMIT CONNECTION DEFAULT statement unlike COMMIT WORK executes a pure database commit on the DEFAULT connection.
Exceptions
Non-Catchable Exceptions
Cause: COMMIT WORK is not possible in a FORM that was called using PERFORM ... ON COMMIT.
Runtime Error: COMMIT_IN_PERFORM_ON_COMMIT
Cause: COMMIT WORK is not allowed in the update.
Runtime Error: COMMIT_IN_POSTING
ROLLBACK WORK
Variants:
1. ROLLBACK WORK.
2. ROLLBACK CONNECTION con.
Effect
Terminates a SAP-LUW without storing the changes.
Variant 1
ROLLBACK WORK.
Effect
The statement ROLLBACK WORK closes the current SAP-LUW and opens a new one. In doing so, all change requests of the current SAP-LUW are canceled. To do this, ROLLBACK WORK carries out the following actions:
Executes all subprograms registered with PERFORM ON ROLLBACK.
Deletes all subprograms registered with PERFORM ON COMMIT.
Raises an internal exception in the Object Services that makes sure that the attributes of persistent objects are initialised.
Deletes all update function modules registered with CALL FUNCTION ...IN UPDATE TASK from the VBLOG and deletes all transactional remote Function Calls registered with CALL FUNCTION ... IN BACKGROUND TASK from ARFCSSTATE and from ARFCSDATA.
Removal of all SAP locks set in the current program in which the formal parameter _SCOPE of the lock function module was set to the value 2.
Triggers a database rollback, which also ends the current database-LUW.
After completion of the statement COMMIT WORK, the event TRANSACTION_FINISHED of the system class CL_SYSTEM_TRANSACTION_STATE is raised, in which the parameter KIND has the value of the constant CL_SYSTEM_TRANSACTION_STATE=>ROLLBACK_WORK.
Variant 2
ROLLBACK CONNECTION con.
Note
This statement is for internal use only.
It cannot be used in application programs.
Effect
The ROLLBACK-statement is not executed on the standard database but only on the secondary database connection, specified through con. con is the name of the database connection as it was specified in table DBCON in column CON_NAME. The database connection con can also be specified dynamically in the form (source_text), in which the field source_text contains the name of the database connection. The field source_text must be of the type C or STRING.
Notes
As all opened database cursors on the respective database connections are closed at ROLLBACK, the attempt to continue a SELECT-loop after a ROLLBACK, leads to a runtime error. Due to the same reason, a FETCH after a ROLLBACK to the then closed cursor, leads to a runtime error. You have to make sure that cursors that are still open, are no longer used after ROLLBACK.
After execution of the statement ROLLBACK, SY-SUBRC is always equal to 0. It is not necessary to check if SY-SUBRC is unequal to 0 after ROLLBACK.
ROLLBACK must not be used during update (CALL FUNCTION ... IN UPDATE TASK) or during the execution of FORMs, which were registered with PERFORM ... ON COMMIT resp. PERFORM ...ON ROLLBACK.
The statement ROLLBACK WORK is implicitly executed if a message of the type A is treated with the addition ERROR_MESSAGE when calling a function module with CALL FUNCTION.
Exceptions
Non-Catchable Exceptions
Cause: ROLLBACK WORK is not allowed within a FORM that is called with PERFORM ... ON COMMIT or PERFORM ... ON ROLLBACK.
Runtime Error: ROLLBACK_IN_PERFORM_ON_COMMIT
Cause: ROLLBACK WORK is not allowed within an update.
Runtime Error: ROLLBACK_IN_POSTING
SET UPDATE TASK LOCAL
Syntax
SET UPDATE TASK LOCAL.
Effect
This statement specifies that the high-priority update function modules - registered during the current SAP LUW using CALL FUNCTION ... IN UPDATE TASK - are registered in the ABAP memory instead of the VBLOG database table. In addition, it specifies that the current work process and not the update work process run these modules during the current database LUW, when the COMMIT WORK statement is executed. This statement has no effect on low-priority update function modules.
At the beginning of every SAP LUW, the local update function is deactivated. If you wish to use it, you must reactivate it again before the first update function module is registered.
System fields
sy-subrc Meaning
0 The local update function is activated.
1 The local update function has not been activated, because the program has already registered at least one update function module for the normal updating procedure in the current SAP-LUW.
Notes
The local update function performs a synchronous update according to the COMMIT WORK statement, independent of the addition AND WAIT.
The occurrence of a database rollback during the local update affects all previous change requests.

How to transfer IDOC - E1EDL24 segment data into my_itab?

Hi Experts,
Am trying to transfer data from a Segment-E1EDL24 to an itab of fs_itm_data.
data: begin of fs_itm_data,
tapos(6),
nista(18),
altme(3),
end of fs_itm_data.
So, when u see this E1EDL24 segment in WE31, there are lot of fields in it.
And am getting the data as,
idoc_data-segnam = E1EDL24
idoc_data-sdata = 00001012345678 (i.e. POSNR+MATNR)
So, to do dump this segment data into itab, am wrting code by using OFF SETTIng ; like,
fs_itm_data-tapos         = edidd-sdata+0(6).
fs_itm_data-nista         = edidd-sdata+146(15).
fs_itm_data-altme         = edidd-sdata+161(3).
1 - but, I dont think that, this is correct practice
2 - if there is no value for Alt UNIT of edidd-sdata+161(3), wht happens?
3 - If MATNR varies in its length, like 1 - 18?
so, let me know that,
1 - How to transfer this segment data into this itab?
THANQ

If I understand ur requirement correctly then u need to move idoc_data-sdata to an internal table itab.In that case no need to move data from idoc_data-sdata to itab directly using OFF SETT.
1st declare one wrokarea of type E1EDL24.
data: w_E1EDL24 type E1EDL24.
Now move the content of idoc_data-sdata to the workarea.
move idoc_data-sdata to w_E1EDL24.
Now u can do field by field assignment to move data from w_E1EDL24 to ur table.
fs_itm_data-tapos = w_E1EDL24-tapos.
fs_itm_data-nista = w_E1EDL24-nista.
fs_itm_data-altme = w_E1EDL24-altme.
Here I am assuming that field names in the structure fs_itm_data are same as field names in the segment w_E1EDL24.
Regards,
Joy.

Logical unit of works

Can some one tell me abt logical unit of work(LUW).

Hi,
A Logical Unit of Work (LUW or database transaction) is an inseparable sequence of database operations which must be executed either in its entirety or not at all. For the database system, it thus constitutes a unit.
LUWs help to guarantee database integrity. When an LUW has been successfully concluded, the database is once again in a correct state. If, however, an error occurs within an LUW, all database changes made since the beginning of the LUW are canceled and the database is then in the same state as before the LUW started.
An LUW begins
o each time you start a transaction
o when the database changes of the previous LUW have been confirmed (database commit) or
o when the database changes of the previous LUW have been cancelled (database rollback)
An LUW ends
o when the database changes have been confirmed (database commit) or
o when the database changes have been canceled (database rollback)
Two types of LUW are:
1) DB LUW - A database LUW is the mechanism used by the database to ensure that its data is always consistent. A database LUW is an inseparable sequence of database operations that ends with a database commit. The database LUW is either fully executed by the database system or not at all. Once a database LUW has been successfully executed, the database will be in a consistent state. If an error occurs within a database LUW, all of the database changes since the beginning of the database LUW are reversed. This leaves the database in the state it had before the transaction started.
2) SAP LUW - A logical unit consisting of dialog steps, whose changes are written to the database in a single database LUW is called an SAP LUW. Unlike a database LUW, an SAP LUW can span several dialog steps, and be executed using a series of different work processes.
More on this .
http://help.sap.com/saphelp_nw2004s/helpdata/en/41/7af4b9a79e11d1950f0000e82de14a/frameset.htm
Regards,
Raghav

Sequencing 3 sceanrios as one logical unit of work

Hi,
I have 3 business services BS1,BS2,BS3
BS1 is source database DB1 which has 2 tables DB1_table1,DB1_table2
BS2 is another source datbase DB2 which has one table DB2_table1
BS3 is target database DB3 which has 2 tables DB3_table1,DB3_table2
And the three scenarios are as below
1.Data from DB1_table1 has to be inseted into DB3_table1 -
from BS1 to BS3
2.Data from DB1_table2 hasto be inserted into DB3_table2 -
from BS1 to BS3
3.Data from DB2_table1 has to be inserted into DB3_table2 -
from BS2 to BS3
But i want all these 3 sceanrios as one logical unit of work and 1,2,3 should be in a sequence.If any one of these fails remaining processes should fail. for ex if 1 fails 2,3 should not occur.
How can i achieve this?
Thanks & Regards,
Jyothsna

Hi,
you can able to achive this using BPM.Check the below links for creating BPM scenarios..
[https://weblogs.sdn.sap.com/pub/wlg/1403 [original link is broken] [original link is broken] [original link is broken]]
[Schedule Your BPM]
[Walkthrough with BPM]
[The specified item was not found.]
[RFC Scenario using BPM --Starter Kit]
[/people/sravya.talanki2/blog/2005/08/24/do-you-like-to-understand-147correlation148-in-xi]
[The specified item was not found.]
[One Logical System Name for serveral BPM Acknowledgements]
[Illustration of Multi-Mapping and Message Split using BPM in SAP Exchange Infrastructure]
[Posting multiple IDocs with Acknowledgement]
Regards,
Prakasu

Bapi and Logical Unit of Work

Hi all,
I am using Bapi to post records in a loop on internal table itab. After posting records, I am again looping at itab and populating those records to my custom table.
Does this scenario use 2 logical unit of work?
If yes, then please tell me how do I use one logical unit of work.
Thanks,
Ridhima

Hey,
You should not post records to the custom table if the BAPI posting has failed.
In order to maintain data consistency the logic in your program should be as below:
LOOP AT itab.
CALL BAPI.
IF BAPI Call is successful
Post data to Custom table.
CALL BAPI_TRANSACTION_COMMIT.
ELSE.
CALL BAPI_TRANSACTION_ROLLBACK.
ENDIF.
ENDLOOP.
Talking about LUW's, any program uses 1 SAP LUW and Multiple Database LUWs depending on the number times you COMMIT the data to the database.
If in your program you were to use only one COMMIT statement or no COMMIT statement at all, your program would use 1 SAP LUW and 1 database LUW.
-Kiran
*Please mark useful answers

RE:logical unit of work

Hi guys,
What do u mean by logical unit of work...Can anyone explain me with an example.
Regards,
Alex.

hi,
this gives complete idea
SAP LUW
Since, as a rule, an application program is processed by several work processes in succession, and every change of the work process is linked with an implicit database commit , an application program is not automatically linked with a single database LUW. This applies in particular to dialog-oriented applications, in which one database LUW is assigned to one dialog step.
To ensure the data consistency of application programs that are executed across different work processes, the application statements are not directly executed in an SAP LUW, rather, are first registered and then executed by a single work process, that is, in a single database LUW.
Two techniques are available for bundling the change statements in a database LUW:
Bundling via function modules (update)
Through the statement CALL FUNCTION...IN UPDATE TASK, an update function module is registered for subsequent execution in an update work process.
Bundling via function modules (transactional RFC)
Through the statement CALL FUNCTION... IN BACKGROUND TASK DESTINATION, a remote- compatible function module is registered for subsequent asynchronous execution via the RFC interface (transactional RFC ).
Bundling via subprograms
Through the statement PERFORM ... ON COMMIT, a subprogram is registered for subsequent execution in a different work process.
Statements for SAP LUWs
A SAP LUW is controlled via the Open SQL statements COMMIT WORK, ROLLBACK WORK and SET UPDATE TASK LOCAL.
Note
A function module can be classified either as an update function module or remote-compatible, but not both at the same time. The update helps realize SAP LUWs within an SAP System, while the transactional RFC creates LUWs in distributed systems.
COMMIT WORK
Variants:
1. COMMIT WORK [AND WAIT].
2. COMMIT CONNECTION con.
Effect
Terminates an SAP LUW and stores the changes.
Variant 1
COMMIT WORK [AND WAIT].
Effect
The statement COMMIT WORK completes the current SAP LUW and opens a new one, storing all change requests for the currenta SAP LUW in the process. In this case, COMMIT WORK performs the following actions:
It executes all subroutines registered using PERFORM ON COMMIT.
It triggers an internal event in Object Services that ensures the registration of changes in persistent objects as the last update function module, as well as the subsequent initialization of persistent object attributes.
It initiates the processing of all registered update function modules in the update work process.
This executes all high-priority update function modules registered using CALL FUNCTION ... IN UPDATE TASK in the order of their registration and in a common database LUW. If you do not specify the addition AND WAIT, the program does not wait until the update work process has executed it (asynchronous updating). If you specify the addition AND WAIT, however, program processing after COMMIT WORK will not continue until the update work process has executed the high-priority update function modules (synchronous updating).
If all high-priority update function modules are completed successfully, the statement executes the low-priority update function modules together in a common database LUW.
In parallel, it also executes the individual function modules registered using CALL FUNCTION ... IN BACKGROUND TASK DESTINATION in a separate database LUW for each destination.
It handles all SAP locks set in the current program according to the value of the formal parameter _SCOPE of the corresponding lock function modules.
It triggers a database commit that also terminates the current database LUW.
The completion of statement COMMIT WORK triggers the event TRANSACTION_FINISHED of the system class CL_SYSTEM_TRANSACTION_STATE, where the parameter KIND has the value of the constant CL_SYSTEM_TRANSACTION_STATE=>COMMIT_WORK.
If the statement COMMIT WORK is executed by calling special programs, be aware of the following:
In a program executed using batch input, or if you have called the program using the USING addition of the statement CALL TRANSACTION, COMMIT WORK terminates the batch input processing when using the corresponding settings.
In a program called using CALL DIALOG, COMMIT WORK initiates the processing of subroutines or updated function modules registered using PERFORM ... ON COMMIT and CALL FUNCTION ... IN UPDATE TASK. Therefore, it does not complete the current SAP LUW. The SAP LUW cannot be completed until you execute the COMMIT WORK statement in the calling program.
You cannot execute the COMMIT WORK statement during the updating procedure or during the execution of subroutines registered using PERFORM ... ON {COMMIT|ROLLBACK}.
System fields
sy-subrc Meaning
0 You have specified the AND WAIT addition, and the updating of the update function modules was successful.
4 You have specified the AND WAIT addition, and the updating of the update function modules was not successful.
The COMMIT WORK statement always sets sy-subrc to 0 if the AND WAIT addition is not specified.
Note
The COMMIT WORK statement closes all database cursors . Open SQL statements that access a database cursor later ( SELECT loop and FETCH) raise an exception that cannot be handled.
Variant 2
COMMIT CONNECTION con.
Note
This statement is for internal use only.
It cannot be used in application programs.
Effect
The COMMIT command is not executed on the standard database, but only on the secondary database connection specified by con. con is the name of the database connection as it was specified in the table DBCON in the column CON_NAME. The database connection con can also be specified dynamically in the form (source_text) - the source_text field contains the name of the database connection. The source_text field must be of the type C or STRING.
On the specified secondary database connection, the database commit:
Closes all open database cursors (OPEN CURSOR)
Releases all database locks
Note
Note that the COMMIT CONNECTION DEFAULT statement unlike COMMIT WORK executes a pure database commit on the DEFAULT connection.
Exceptions
Non-Catchable Exceptions
Cause: COMMIT WORK is not possible in a FORM that was called using PERFORM ... ON COMMIT.
Runtime Error: COMMIT_IN_PERFORM_ON_COMMIT
Cause: COMMIT WORK is not allowed in the update.
Runtime Error: COMMIT_IN_POSTING
ROLLBACK WORK
Variants:
1. ROLLBACK WORK.
2. ROLLBACK CONNECTION con.
Effect
Terminates a SAP-LUW without storing the changes.
Variant 1
ROLLBACK WORK.
Effect
The statement ROLLBACK WORK closes the current SAP-LUW and opens a new one. In doing so, all change requests of the current SAP-LUW are canceled. To do this, ROLLBACK WORK carries out the following actions:
Executes all subprograms registered with PERFORM ON ROLLBACK.
Deletes all subprograms registered with PERFORM ON COMMIT.
Raises an internal exception in the Object Services that makes sure that the attributes of persistent objects are initialised.
Deletes all update function modules registered with CALL FUNCTION ...IN UPDATE TASK from the VBLOG and deletes all transactional remote Function Calls registered with CALL FUNCTION ... IN BACKGROUND TASK from ARFCSSTATE and from ARFCSDATA.
Removal of all SAP locks set in the current program in which the formal parameter _SCOPE of the lock function module was set to the value 2.
Triggers a database rollback, which also ends the current database-LUW.
After completion of the statement COMMIT WORK, the event TRANSACTION_FINISHED of the system class CL_SYSTEM_TRANSACTION_STATE is raised, in which the parameter KIND has the value of the constant CL_SYSTEM_TRANSACTION_STATE=>ROLLBACK_WORK.
Variant 2
ROLLBACK CONNECTION con.
Note
This statement is for internal use only.
It cannot be used in application programs.
Effect
The ROLLBACK-statement is not executed on the standard database but only on the secondary database connection, specified through con. con is the name of the database connection as it was specified in table DBCON in column CON_NAME. The database connection con can also be specified dynamically in the form (source_text), in which the field source_text contains the name of the database connection. The field source_text must be of the type C or STRING.
Notes
As all opened database cursors on the respective database connections are closed at ROLLBACK, the attempt to continue a SELECT-loop after a ROLLBACK, leads to a runtime error. Due to the same reason, a FETCH after a ROLLBACK to the then closed cursor, leads to a runtime error. You have to make sure that cursors that are still open, are no longer used after ROLLBACK.
After execution of the statement ROLLBACK, SY-SUBRC is always equal to 0. It is not necessary to check if SY-SUBRC is unequal to 0 after ROLLBACK.
ROLLBACK must not be used during update (CALL FUNCTION ... IN UPDATE TASK) or during the execution of FORMs, which were registered with PERFORM ... ON COMMIT resp. PERFORM ...ON ROLLBACK.
The statement ROLLBACK WORK is implicitly executed if a message of the type A is treated with the addition ERROR_MESSAGE when calling a function module with CALL FUNCTION.
Exceptions
Non-Catchable Exceptions
Cause: ROLLBACK WORK is not allowed within a FORM that is called with PERFORM ... ON COMMIT or PERFORM ... ON ROLLBACK.
Runtime Error: ROLLBACK_IN_PERFORM_ON_COMMIT
Cause: ROLLBACK WORK is not allowed within an update.
Runtime Error: ROLLBACK_IN_POSTING
SET UPDATE TASK LOCAL
Syntax
SET UPDATE TASK LOCAL.
Effect
This statement specifies that the high-priority update function modules - registered during the current SAP LUW using CALL FUNCTION ... IN UPDATE TASK - are registered in the ABAP memory instead of the VBLOG database table. In addition, it specifies that the current work process and not the update work process run these modules during the current database LUW, when the COMMIT WORK statement is executed. This statement has no effect on low-priority update function modules.
At the beginning of every SAP LUW, the local update function is deactivated. If you wish to use it, you must reactivate it again before the first update function module is registered.
System fields
sy-subrc Meaning
0 The local update function is activated.
1 The local update function has not been activated, because the program has already registered at least one update function module for the normal updating procedure in the current SAP-LUW.
Notes
The local update function performs a synchronous update according to the COMMIT WORK statement, independent of the addition AND WAIT.
The occurrence of a database rollback during the local update affects all previous change requests.
Regards
vasu

Can I create my own logical unit of work (LUW)?

Good day, everyone!
This is an off-shoot to a Why does the NOCOMMIT parameter not work in HR_INFOTYPE_OPERATION? yesterday in this forum.
It appears that the FM I'm calling is going to do a commit, no matter what. The only thing I can tell is that the NOCOMMIT parameter is used to do a rollback only in the event of a problem.
What I'd like to do is somehow "encapsulate" my call to this function with my own "LUW" designation so that, depending on what a user selects in a selection screen (run as test only? checkbox) I can rollback changes on my own. Unfortunately, I don't know if this is even possible and, if so, how to do it. I need to do something because the end users running this function would like to be able to do a "test run" of all the address transactions to see if there's any errors, data that still needs cleaned up, etc.
Any ideas? Points awarded for all helpful answers, as always.

Hai Dave Packard
Go through the following Link
For Logical database
Logical Unit of Work (LUW)
A Logical Unit of Work (LUW or database transaction) is an inseparable sequence of database operations which must be executed either in its entirety or not at all. For the database system, it thus constitutes a unit.
LUWs help to guarantee database integrity. When an LUW has been successfully concluded, the database is once again in a correct state. If, however, an error occurs within an LUW, all database changes made since the beginning of the LUW are canceled and the database is then in the same state as before the LUW started.
An LUW begins
each time you start a transaction
when the database changes of the previous LUW have been confirmed (database commit) or
when the database changes of the previous LUW have been cancelled (database rollback)
An LUW ends
when the database changes have been confirmed (database commit) or
when the database changes have been canceled (database rollback)
Database commit and rollback
Within an LUW, database changes are not made until after a database commit. Prior to this, any database change can be canceled by a database rollback.
In the R/3 System, a database commit is triggered either automatically or by the ABAP/4 command COMMIT WORK or the appropriate Native SQL command for the database system.
Similarly, a database rollback is triggered either automatically or by the ABAP/4 command ROLLBACK WORK or the appropriate Native SQL command for the database system.
A database commit is triggered automatically by
each screen change, and especially after the ABAP/4 commands CALL SCREEN, CALL DIALOG, CALL TRANSACTION, MESSAGE or
a Remote Function Call
A database rollback is triggered automatically by
errors which occur at runtime or
the ABAP/4 command MESSAGE with the message type 'A'
After each database commit or rollback, the database locks set in the LUW are released (see Database Locking).
Thanks & regards
Sreenivasulu P
Message was edited by: Sreenivasulu Ponnadi

Related to LUW(logical unit of work)

Hi Experts,
 Based on an inbound idoc i need to change some data in delivery. SD_DELIVERY_UPDATE_PICKING is used to update delivery(PGI details). And also i need to change some other data(which is not possible with the above function module), so i used WS_DELIVERY_UPDATE.
 But the problem is these 2 function modules are calling the standard SAP routines which are used in the program(SAPLV50L) which used for VL02N.
 Now i changed my code, instead of FM WS_DELIVERY_UPDATE i used BDC, now it is giving error like 'This delivery(number) is currently processed by another user (my user id) which means i am trying to change it in same program.
 How can i use these above 2 Function modules in my program. Even i am using COMMIT WORK it creates problem.
 Is there any Function module or any command(other than COMMIT WORK) to ends a LUW(Logical Unit of Work).
 I need your inputs.
cheers,
Bujji

Hi,
 You can do one thing to over come this problem.....
After calling the 1st function module .....using do --while loop check if the update has taken place by checking the tables.......Once its done you can call the second function module......
I think we can also check for locked objects ....let me think over it
regards,
vijay

Cannot capture Segment data in enhancement spot

Hi!
I am developing inbound IDOC for message type COND_A04, i have created a child Z-segement for E1KOMG, i am coding my logic in FM IDOC_INPUT_COND_A in enhancement spot ES_SAPLVKOI, in performs read_seg_e1komg and read_seg_e1konp,
Here in my code i want to capture my Z-segment data in read_seg_e1konp, but its getting cleared before entering into this subroutine, i need my Z_segment data for validation in read_seg_e1konp subroutine,
Can anybody give some idea how to capture data of my Z-segement in this subroutine read_seg_e1konp.

Hi Rajesh,
Check also the other exit (CALL CUSTOMER-FUNCTION '002')
available in FM IDOC_INPUT_COND_A, it may have the data required by you.
Rajeev

Logical units in DB-Tablespace,extent, segments, data blocks

Similar Messages

Maybe you are looking for