Indexed Ordered Tables or Not?
I am designing a database and have a question about the use of Indexed Ordered Tables. All tables in the database have a single column primary key. It is a numeric value select from a sequence. The table will be partitioned by date, one partition per month. The 13th partition will be removed each month. Rows will not typically be deleted.
Would performance be better using Indexed Ordered Tables or Heap Tables?
You generally want to use index-organized tables (IOT) when at least one of the following is true
- the primary key encompasses all the rows of the table
- the table is accessed frequently by the primary key
- you want to enforce co-location of data (i.e. all the orders for a particular customer are stored next to each other)
Of course, you probably want to benchmark with a standard heap organized table and with an index-organized table to be sure.
Justin
Distributed Database Consulting, Inc.
http://www.ddbcinc.com/askDDBC
Similar Messages
-
Export table does not match no. of rows
Tried to export one table from a database and it does not capture all rows. Here's a snapshot from the export and select statement:
Oracle Database 10g Enterprise Edition Release 10.2.0.3.0 - Production
SQL> select count(*) from user1.domain;
COUNT(*)
1342
SQL> exit
Disconnected from Oracle Database 10g Enterprise Edition Release 10.2.0.3.0 - Production
C:\exp user1/user1@user1 tables=DOMAIN full=n file=c:\domain.dmp log=c:\domain.log rows=y indexes=n
Export: Release 10.2.0.3.0 - Production on Fri May 21 10:04:10 2010
Connected to: Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - Production
Export done in WE8MSWIN1252 character set and AL16UTF16 NCHAR character set
Note: indexes on tables will not be exported
About to export specified tables via Conventional Path ...
. . exporting table ALNDOMAIN 1338 rows exported
Export terminated successfully without warnings.SQL> select count(*) from user1.domain;
COUNT(*)-- selecting from table user1.domain
About to export specified tables via Conventional Path ...
. . exporting table ALNDOMAIN 1338 rows exported-- exporting table ALNDOMAIN
They seem different tables.
Try:
exp user1/user1@user1 tables=user1.domain file=c:\domain.dmp log=c:\domain.log rows=y indexes=nHTH -
Text Index works fine consistently with Table, but not on underlying View
Hi,
We are facing weird issue relating to Oracle Text Indexes. Search using Oracle Text Index
works fine on a Table, but when running query on View it gives sometimes (not consistently)
ORA-20000: Oracle Text error:
DRG-10849: catsearch does not support functional invocation
DRG-10599: column is not indexed
Sometimes it works.
All of the below steps are run using User IR2OWNER:
STEP 1: Table CPF_CUSTOMER created as follows (3 Non Text Indexes defined at time of creation )
**Please note no Public Synonym is created for this Table**
** There is already another Table by same name CPF_CUSTOMER under different Owner (CDROWNER)
and that Table has Public Synonym CPF_CUSTOMER created. Other Table CPF_CUSTOMER does not
have any Views **
create table CPF_CUSTOMER
CPF_CUSTOMER_UUID NUMBER(20) not null,
SAP_ID VARCHAR2(10 CHAR) not null,
IRIS2_ID VARCHAR2(7 CHAR),
NAME VARCHAR2(70 CHAR) not null,
DRAFT_IND NUMBER(1) not null,
ACTIVE_IND NUMBER(1) not null,
REPLACED_BY_CUST VARCHAR2(10 CHAR),
CRE_DT_GMT DATE,
CRE_DT_LOC DATE,
TIME_ZONE VARCHAR2(3 CHAR),
CRE_USR VARCHAR2(8 CHAR),
CHG_DT_GMT DATE,
CHG_DT_LOC DATE,
CHG_TIME_ZONE VARCHAR2(3 CHAR),
CHG_USR VARCHAR2(8 CHAR),
VFY_DT_GMT DATE,
VFY_DT_LOC DATE,
VFY_USR VARCHAR2(8 CHAR),
DIVISION VARCHAR2(20 CHAR),
SALES_ADMIN VARCHAR2(3 CHAR),
MF_CUST_CDE VARCHAR2(14 CHAR),
CR_CTRL_OFCE VARCHAR2(3 CHAR),
DEFAULT_INV_CCY VARCHAR2(3 CHAR),
AUTOBILL_OVRRD_IND NUMBER(1) not null,
AUTOBILL NUMBER(1) not null,
AUTOPRT_OVRRD_IND NUMBER(1) not null,
AUTOPRT NUMBER(1) not null,
AVE_PYMT_DAY NUMBER(3),
TTL_INV_VAL NUMBER(12,2),
INHERIT_CR_TERM_ASSGMT NUMBER(1) not null,
NORMALIZED_NME VARCHAR2(70 CHAR),
OB_PYMT_OFCE VARCHAR2(3 CHAR),
IB_PYMT_OFCE VARCHAR2(3 CHAR),
CGO_SMART_ID VARCHAR2(20 CHAR),
REC_UPD_DT TIMESTAMP(6),
NCPF_CUST_ID VARCHAR2(7) not null,
CPF_CUST_LEVEL_UUID NUMBER(20) not null
tablespace DBCPFP1_LG_DATA LOGGING;
CREATE UNIQUE INDEX CPF_CUSTOMERI1 ON CPF_CUSTOMER
(SAP_ID ASC) TABLESPACE DBCPFP1_LG_INDX;
ALTER TABLE CPF_CUSTOMER
ADD CONSTRAINT CPF_CUSTOMERI1 UNIQUE (SAP_ID);
CREATE UNIQUE INDEX CPF_CUSTOMERI2 ON CPF_CUSTOMER
(CPF_CUSTOMER_UUID ASC) TABLESPACE DBCPFP1_LG_INDX;
ALTER TABLE CPF_CUSTOMER
ADD CONSTRAINT CPF_CUSTOMERI2 UNIQUE (CPF_CUSTOMER_UUID);
CREATE INDEX CPF_CUSTOMER_IDX2 ON CPF_CUSTOMER (UPPER(NAME))
TABLESPACE DBCPFP1_LG_INDX;
STEP 2: Create View CPF_CUSTOMER_RVW on above Table (and Public Synonym on View)
This View is created under same OWNER as Table created in STEP 1 (IR2OWNER)
create or replace view cpf_customer_rvw as
select
CPF_CUSTOMER_UUID,
SAP_ID,
IRIS2_ID,
NAME,
DRAFT_IND,
ACTIVE_IND,
REPLACED_BY_CUST,
CRE_DT_GMT,
CRE_DT_LOC,
TIME_ZONE,
CRE_USR,
CHG_DT_GMT,
CHG_DT_LOC,
CHG_TIME_ZONE,
CHG_USR,
VFY_DT_GMT,
VFY_DT_LOC,
VFY_USR,
DIVISION,
SALES_ADMIN,
MF_CUST_CDE,
CR_CTRL_OFCE,
DEFAULT_INV_CCY,
AUTOBILL_OVRRD_IND,
AUTOBILL,
AUTOPRT_OVRRD_IND,
AUTOPRT,
AVE_PYMT_DAY,
TTL_INV_VAL,
INHERIT_CR_TERM_ASSGMT,
NORMALIZED_NME,
OB_PYMT_OFCE,
IB_PYMT_OFCE,
CGO_SMART_ID,
NCPF_CUST_ID,
CPF_CUST_LEVEL_UUID,
REC_UPD_DT
from CPF_CUSTOMER;
CREATE OR REPLACE PUBLIC SYNONYM CPF_CUSTOMER_RVW FOR CPF_CUSTOMER_RVW;
STEP 3: Insert Test row
insert into cpf_customer (CPF_CUSTOMER_UUID, SAP_ID, IRIS2_ID, NAME, DRAFT_IND, ACTIVE_IND, REPLACED_BY_CUST, CRE_DT_GMT, CRE_DT_LOC, TIME_ZONE, CRE_USR, CHG_DT_GMT, CHG_DT_LOC, CHG_TIME_ZONE, CHG_USR, VFY_DT_GMT, VFY_DT_LOC, VFY_USR, DIVISION, SALES_ADMIN, MF_CUST_CDE, CR_CTRL_OFCE, DEFAULT_INV_CCY, AUTOBILL_OVRRD_IND, AUTOBILL, AUTOPRT_OVRRD_IND, AUTOPRT, AVE_PYMT_DAY, TTL_INV_VAL, INHERIT_CR_TERM_ASSGMT, NORMALIZED_NME, OB_PYMT_OFCE, IB_PYMT_OFCE, CGO_SMART_ID, NCPF_CUST_ID, CPF_CUST_LEVEL_UUID, REC_UPD_DT)
values (2.26283572796028E15, '6588125000', '6588125', 'S M Mooseen And Sons(PVT) Limited', 0, 1, '', to_date('15-03-2005 08:55:00', 'dd-mm-yyyy hh24:mi:ss'), to_date('15-03-2005 14:25:00', 'dd-mm-yyyy hh24:mi:ss'), 'IST', 'licr2', to_date('19-02-2007 00:33:00', 'dd-mm-yyyy hh24:mi:ss'), to_date('19-02-2007 06:03:00', 'dd-mm-yyyy hh24:mi:ss'), 'IST', 'BaseAdmi', to_date('15-03-2005 09:03:00', 'dd-mm-yyyy hh24:mi:ss'), to_date('15-03-2005 14:33:00', 'dd-mm-yyyy hh24:mi:ss'), 'ninwasa', '', '', 'SRI06588125000', '463', '', 0, 0, 0, 0, null, null, 0, 'SMMOOSEENANDSONSPVTLIMITED', '', '', '', '6588125', 109966195050333, '14-JAN-09 02.49.28.325774 PM');
commit;
STEP 4: Create Oracle Text Index on Table CPF_CUSTOMER
EXEC CTX_DDL.DROP_PREFERENCE('CTXCAT_IR2_STORAGE');
EXEC CTX_DDL.CREATE_PREFERENCE('CTXCAT_IR2_STORAGE', 'BASIC_STORAGE');
EXEC CTX_DDL.SET_ATTRIBUTE('CTXCAT_IR2_STORAGE', 'I_INDEX_CLAUSE', 'TABLESPACE COMMON_SM_INDX COMPRESS 2');
EXEC CTX_DDL.SET_ATTRIBUTE('CTXCAT_IR2_STORAGE', 'I_INDEX_CLAUSE', 'TABLESPACE COMMON_SM_INDX COMPRESS 2');
EXEC CTX_DDL.SET_ATTRIBUTE('CTXCAT_IR2_STORAGE', 'K_TABLE_CLAUSE', 'TABLESPACE COMMON_SM_INDX COMPRESS 2');
EXEC CTX_DDL.SET_ATTRIBUTE('CTXCAT_IR2_STORAGE', 'R_TABLE_CLAUSE', 'TABLESPACE COMMON_SM_INDX COMPRESS 2');
EXEC CTX_DDL.SET_ATTRIBUTE('CTXCAT_IR2_STORAGE', 'I_ROWID_INDEX_CLAUSE', 'TABLESPACE COMMON_SM_INDX storage (INITIAL 5M)');
-- Define IR2_AB_LEXER to handle Special Characters.
EXEC ctx_ddl.drop_preference('IR2_AB_LEXER');
EXEC ctx_ddl.create_preference('IR2_AB_LEXER', 'BASIC_LEXER');
EXEC ctx_ddl.set_attribute ('IR2_AB_LEXER', 'printjoins', ',_!$~%?=({;|&+-:/)}.@`^');
--Drop Indexes
drop index CPF_CUSTOMER_DIDX1;
-- CATSEARCH INDEX on CPF_CUSTOMER.NAME
CREATE INDEX CPF_CUSTOMER_DIDX1 ON CPF_CUSTOMER(NAME) INDEXTYPE IS CTXSYS.CTXCAT PARAMETERS ('STORAGE CTXCAT_IR2_STORAGE STOPLIST CTXSYS.EMPTY_STOPLIST LEXER IR2_AB_LEXER');
commit;
STEP 5: Run Query to use Oracle Text Index on Base Table (works fine always. No issues seen so far)
SELECT a.sap_id||'|'||a.name||'|' CUSTOMER_STR
FROM cpf_customer a
WHERE (catsearch(a.name, 'Mooseen'||'*', '')>0);
CUSTOMER_STR
6588125000|S M Mooseen And Sons(PVT) Limited|
STEP 6: Run Query to use Oracle Text Index on View created under Table (get below error periodically)
ORA-20000: Oracle Text error:
DRG-10849: catsearch does not support functional invocation
DRG-10599: column is not indexed
But it works sometimes as in STEP 5 and returns 1 row. It is never consistent. We would like to
provide access to this Table using View only. That is why we would like to get this query working consistently
using View.
Any help or tips would be greatly appreciated
Thanks
AuroThis is a known issue with CTXCAT indexes. Sometimes the optimizer will "drive" the query off another index, and request results from the CTXCAT index on a row-by-row basis ("does the row with rowid NNNN satisfy this CATSEARCH condition?"). That's known as a functional lookup, and is not supported by the CTXCAT indextype.
The only solution is to try to persuade the optimizer to use a different plan which does not use a functional lookup. This can be achieved by the use of hints, or sometimes by collecting or deleting statistics on the table. -
Index for a PSA table is not in the "customer" namespace
Hi,
While loading data through infosource 0CO_OM_WBS_1 to
data target 0IMFA_1 loading failes and the reason given is that the system reads data from PSA table /BIC/B0001060000 of 0IM_FA_IQ_9 and the index generated for this table supplied return code 14.
I found no notes in the subject - with the syntax :
Index for a PSA table is not in the "customer" namespace.
thanks in advance for your help.Hi,
I think you need to speak to your basis guys / DBA as index created on PSA table is not in your tablespace. He should be able to help you.
Vikash -
Order table not opened in datablock Wizard in developer 9i
there is an error dispalying whenever user going to open ORDER table in datablock wizard under Forms builder, the error is :
FRM-10095:Assertion failed in iewbdbc_oracle_to_id, at E:/f021W32/src/ie/jewbdc.C:715
Whereas, there is no for there in E drive.
Even, when Customer table is open, Item Phone Number is disable.
What type of problem these are? & how to solve & open the orders & customers tables ?
Edited by: user11082236 on Nov 9, 2009 8:55 AMWere the Oracle binaries or form copied from another server ? Were they relinked and recompiled after copy ?
This is a forms development issue, so the DBA forum is not really the best plact to ask it. -
Thin driver is not supported in PL/SQL Index-by Tables Sample Applications
I have downloaded PL/SQL Index-by Tables Sample Application and running on JDeveloper 10g. It is giving me SQLExceprion Not supported. It works if I change the driver type to oci. Can anyone please help me how to run same application using thin.
Thanks in advance
RatanCan you provide the info. for the Jdbc version and the database version that you are using? thanks.
-cc -
Automatic form generation on creation transfer order for delivery note?
Hi,
I have to create a form that should automatically be generated on the creation of a transfer order for delivery note. How do I trigger this automatic creation of the form? And how can the transfer order number be passed to my print program?
Thx!hi christophe,
To issue the delivery output, go to transaction VL02N.
Then go to EXTRAS-> OUTPUT->HEADER->EDIT
In the Message output screen enter the relevant output type created for the delivery.
Choose the relevant medium of output.
Choose Simple Mail, in this case the field NAST-NACHA will be having a value of 7.
Specify the Partner Function; in this case it is MA -> Mail partner address
Select the Communication Method for the output type maintained.
This will take you to the SAPOFFICE screen.
Enter there the E-Mail Address to which you want to send the delivery document as PDF.
A mail will be sent to the e-mail address of the E-Mail Address specified, with the delivery output form as a PDF attachment.
hope it will help u ..
*& Report ZZ_TEST *
REPORT zz_test .
INCLUDE zz_test_top.
INCLUDE zz_test01.
FORM entry *
--> RETURN_CODE *
--> US_SCREEN *
FORM entry USING return_code us_screen.
CLEAR retcode.
xscreen = us_screen.
PERFORM processing USING us_screen.
CASE retcode.
WHEN 0.
return_code = 0.
WHEN 3.
return_code = 3.
WHEN OTHERS.
return_code = 1.
ENDCASE.
ENDFORM. "entry
*& Include ZZ_TEST_TOP *
TABLES : nast,
tnapr.
TYPES : BEGIN OF t_SOUDNAMEI1.
INCLUDE STRUCTURE SOUDNAMEI1.
TYPES : END OF t_SOUDNAMEI1.
Internal Table declarations
DATA: i_otf TYPE itcoo OCCURS 0 WITH HEADER LINE,
i_tline TYPE TABLE OF tline WITH HEADER LINE,
i_receivers TYPE TABLE OF somlreci1 WITH HEADER LINE,
i_record LIKE solisti1 OCCURS 0 WITH HEADER LINE,
*Objects to send mail.
i_objpack LIKE sopcklsti1 OCCURS 0 WITH HEADER LINE,
i_objtxt LIKE solisti1 OCCURS 0 WITH HEADER LINE,
i_objbin LIKE solisti1 OCCURS 0 WITH HEADER LINE,
i_reclist LIKE somlreci1 OCCURS 0 WITH HEADER LINE,
i_lips LIKE lips OCCURS 0 WITH HEADER LINE,
i_SOUDNAMEI1 TYPE STANDARD TABLE OF t_SOUDNAMEI1.
Work Area declarations
DATA:w_objhead TYPE soli_tab,
wa_control_parameters TYPE ssfctrlop,
wa_output_options TYPE ssfcompop,
w_return TYPE ssfcrescl,
w_doc_chng TYPE sodocchgi1,
w_data TYPE sodocchgi1,
w_buffer TYPE string,"To convert from 132 to 255
wa_SOUDNAMEI1 TYPE t_SOUDNAMEI1,
Variables declarations
w_form_name TYPE rs38l_fnam,
w_len_in LIKE sood-objlen,
w_len_out LIKE sood-objlen,
w_len_outn TYPE i,
w_lines_txt TYPE i,
w_lines_bin TYPE i,
retcode TYPE sy-subrc,
xscreen TYPE c,
w_spld TYPE usr01-spld,
w_receiver TYPE SOXNA-FULLNAME,
w_OBJ_RECORD TYPE OBJ_RECORD,
w_user type sy-uname,
w_email TYPE ad_smtpadr.
Constants Declaration
CONSTANTS : c_x TYPE c VALUE 'X',
c_atrate(1) TYPE c VALUE '@'.
*& Include ZZ_TEST01 *
FORM PROCESSING *
FORM processing USING proc_screen.
SELECT * FROM lips
INTO TABLE i_lips
WHERE vbeln = nast-objky.
Call Function module to Getfunction Module name Generated by Smartform
CALL FUNCTION 'SSF_FUNCTION_MODULE_NAME'
EXPORTING
formname = tnapr-sform
IMPORTING
fm_name = w_form_name
EXCEPTIONS
no_form = 1
no_function_module = 2
OTHERS = 3.
IF sy-subrc <> 0.
retcode = sy-subrc.
ENDIF.
CLEAR : wa_control_parameters,
wa_output_options.
CASE nast-nacha.
WHEN '1'.
wa_control_parameters-device = 'PRINTER'.
WHEN '7'.
DATA: l_email TYPE ad_smtpadr.
wa_output_options-tdnoprev = c_x.
wa_control_parameters-getotf = c_x.
To get the default output device maintained in the
User profile
SELECT SINGLE spld FROM usr01
INTO w_spld
WHERE bname EQ nast-usnam.
IF sy-subrc EQ 0.
MOVE w_spld TO wa_output_options-tddest .
ENDIF.
wa_output_options-tdnoprev = c_x.
wa_control_parameters-getotf = c_x.
To get the email address maintained for the particular output
CALL FUNCTION 'NAST_GET_MESSAGE_OBJECT_RECV'
EXPORTING
pi_objkey = nast-tdname
IMPORTING
pe_addr = w_receiver
CHANGING
pc_objhandle = w_obj_record
EXCEPTIONS
maildata_not_readable = 1
OTHERS = 2.
IF sy-subrc <> 0.
MESSAGE ID sy-msgid TYPE sy-msgty NUMBER sy-msgno
WITH sy-msgv1 sy-msgv2 sy-msgv3 sy-msgv4.
ENDIF.
IF w_receiver NA c_atrate.
To retrieve the E-Mail Id in case we get the User name from NAST
CLEAR wa_soudnamei1.
REFRESH i_soudnamei1.
MOVE w_receiver TO wa_soudnamei1-fullname.
To get the user name
CALL FUNCTION 'SO_NAME_CONVERT_API1'
EXPORTING
name = wa_soudnamei1
TABLES
names = i_soudnamei1
EXCEPTIONS
user_not_exist = 1
parameter_error = 2
x_error = 3
OTHERS = 4.
IF sy-subrc <> 0.
MESSAGE ID sy-msgid TYPE sy-msgty NUMBER sy-msgno
WITH sy-msgv1 sy-msgv2 sy-msgv3 sy-msgv4.
ENDIF.
CLEAR wa_soudnamei1.
READ TABLE i_soudnamei1 INTO wa_soudnamei1 INDEX 1.
MOVE wa_soudnamei1-sapname TO w_user.
To get the e-mail Id maintained in the user profile
CALL FUNCTION 'FTR_CORR_CHECK_EMAIL_SAP_USER'
EXPORTING
i_user = w_user
IMPORTING
e_email_address = l_email
EXCEPTIONS
mail_address = 1
determination_error = 2
OTHERS = 3.
IF sy-subrc <> 0.
MESSAGE ID sy-msgid TYPE sy-msgty NUMBER sy-msgno
WITH sy-msgv1 sy-msgv2 sy-msgv3 sy-msgv4.
ENDIF.
MOVE l_email TO w_receiver.
ENDIF.
MOVE w_receiver TO w_email.
ENDCASE.
wa_control_parameters-no_dialog = c_x.
wa_control_parameters-langu = nast-spras .
wa_output_options-tdteleland = nast-tland.
wa_output_options-tdtelenum = nast-telfx .
wa_output_options-tdsenddate = nast-erdat .
wa_output_options-tdsendtime = nast-eruhr .
wa_output_options-tddataset = nast-dsnam .
wa_output_options-tdsuffix1 = nast-dsuf1 .
wa_output_options-tdsuffix2 = nast-dsuf2 .
wa_output_options-tdimmed = nast-dimme .
wa_output_options-tddelete = nast-delet .
wa_output_options-tdautority = nast-tdautority.
wa_output_options-tdcovtitle = nast-tdcovtitle .
wa_output_options-tdcover = nast-tdocover .
wa_output_options-tdreceiver = nast-tdreceiver.
wa_output_options-tddivision = nast-tddivision.
wa_output_options-tdcopies = nast-anzal .
wa_output_options-tdnewid = c_x.
wa_output_options-tdarmod = nast-tdarmod.
wa_output_options-tdnoarmch = c_x.
CALL FUNCTION w_form_name
EXPORTING
archive_index = toa_dara
archive_parameters = arc_params
control_parameters = wa_control_parameters
output_options = wa_output_options
user_settings = ' '
IMPORTING
job_output_info = w_return
TABLES
it_lips = i_lips
EXCEPTIONS
formatting_error = 1
internal_error = 2
send_error = 3
user_canceled = 4
OTHERS = 5.
IF nast-nacha EQ 7 AND sy-subrc EQ 0.
i_otf[] = w_return-otfdata[].
CALL FUNCTION 'CONVERT_OTF'
EXPORTING
format = 'PDF'
max_linewidth = 132
IMPORTING
bin_filesize = w_len_in
TABLES
otf = i_otf
lines = i_tline
EXCEPTIONS
err_max_linewidth = 1
err_format = 2
err_conv_not_possible = 3
OTHERS = 4.
IF sy-subrc <> 0.
MESSAGE ID sy-msgid TYPE sy-msgty NUMBER sy-msgno
WITH sy-msgv1 sy-msgv2 sy-msgv3 sy-msgv4.
ENDIF.
Convert PDF from 132 to 255.
LOOP AT i_tline.
Replacing space by ~
TRANSLATE i_tline USING ' ~'.
CONCATENATE w_buffer i_tline INTO w_buffer.
ENDLOOP.
Replacing ~ by space
TRANSLATE w_buffer USING '~ '.
DO.
i_record = w_buffer.
Appending 255 characters as a record
APPEND i_record.
SHIFT w_buffer LEFT BY 255 PLACES.
IF w_buffer IS INITIAL.
EXIT.
ENDIF.
ENDDO.
REFRESH: i_reclist,
i_objtxt,
i_objbin,
i_objpack.
CLEAR w_objhead.
Object with PDF.
i_objbin[] = i_record[].
DESCRIBE TABLE i_objbin LINES w_lines_bin.
Document information.
w_doc_chng-obj_name = 'Smartform'.
w_doc_chng-expiry_dat = sy-datum + 10.
CONCATENATE 'Delivery' 'Note'
INTO w_doc_chng-obj_descr.
*w_doc_chng-obj_descr = 'Smart form output'.
w_doc_chng-sensitivty = 'F'. "Functional object
w_doc_chng-doc_size = w_lines_txt * 255.
Pack to main body as RAW.
Obj. to be transported not in binary form
CLEAR i_objpack-transf_bin.
Start line of object header in transport packet
i_objpack-head_start = 1.
Number of lines of an object header in object packet
i_objpack-head_num = 0.
Start line of object contents in an object packet
i_objpack-body_start = 1.
Number of lines of the object contents in an object packet
i_objpack-body_num = w_lines_txt.
Code for document class
i_objpack-doc_type = 'RAW'.
APPEND i_objpack.
Packing as PDF.
i_objpack-transf_bin = 'X'.
i_objpack-head_start = 1.
i_objpack-head_num = 1.
i_objpack-body_start = 1.
i_objpack-body_num = w_lines_bin.
i_objpack-doc_type = 'PDF'.
i_objpack-obj_name = 'Smartform'.
CONCATENATE 'Delivery' 'Note' '.pdf'
INTO i_objpack-obj_descr.
i_objpack-doc_size = w_lines_bin * 255.
APPEND i_objpack.
Document information.
CLEAR i_reclist.
e-mail receivers.
i_reclist-receiver = w_email.
i_reclist-express = 'X'.
i_reclist-rec_type = 'U'. "Internet address
APPEND i_reclist.
sending mail.
CALL FUNCTION 'SO_NEW_DOCUMENT_ATT_SEND_API1'
EXPORTING
document_data = w_doc_chng
put_in_outbox = 'X'
TABLES
packing_list = i_objpack
object_header = w_objhead
contents_bin = i_objbin
contents_txt = i_objtxt
receivers = i_reclist
EXCEPTIONS
too_many_receivers = 1
document_not_sent = 2
document_type_not_exist = 3
operation_no_authorization = 4
parameter_error = 5
x_error = 6
enqueue_error = 7
OTHERS = 8.
IF sy-subrc <> 0.
MESSAGE ID sy-msgid TYPE sy-msgty NUMBER sy-msgno
WITH sy-msgv1 sy-msgv2 sy-msgv3 sy-msgv4.
ENDIF.
ENDIF.
ENDFORM. "processing -
what is logical rowid in IOT?are they stored somwhere physically just like physical rowId's
what are secondary indexes?
what it means by leaf block splits?when and how it happens?
and the primary key constraint for an index-organized table cannot be dropped, deferred, or disabled,,,,,Is it true,,,,,if Yes Then Y
how does overflow works?how the two clauses are implemented PCTTHRESHOLD and INCLUDING.how they work?
Edited by: Juhi on Oct 22, 2008 1:09 PMI'm sort-of tempted to just point you in the direction of the official documentation (the concepts guide would be a start. See http://download.oracle.com/docs/cd/B28359_01/server.111/b28318/schema.htm#sthref759)
But I would say one or two other things.
First, physical rowids are not stored physically. I don't know why you'd think they were. The ROWID data type can certainly be used to store a rowid if you choose to do so, but if you do something like 'select rowid from scott.emp', for example, you'll see rowids that are generated on-the-fly. ROWID is a pseudo-column, not physically stored anywhere, but computed whenever needed.
The difference between a physical rowid and a logical one used with IOTs comes down to a bit of relational database theory. It is a cast-iron rule of relational databases that a row, once inserted into a table, must never move. That is, the rowid it is assigned at the moment of its first insertion, must be the rowid it 'holds onto' for ever and ever. If you ever want to change the rowids assigned to rows in an ordinary table, you have to export them, truncate the table and then re-insert them: fresh insert, fresh rowid. (Oracle bends this rule for various maintenance and management purposes, whereby 'enable row movement' permits rows to move within a table, but the general case still applies mostly).
That rule is obviously hopeless for index structures. Were it true, an index entry for 'Bob' who gets updated to 'Robert' would find itself next to entries for 'Adam' and 'Charlie', even though it now has an 'R' value. Effectively, a 'b' "row" in an index must be allowed to "move" to an 'r' sort of block if that's the sort of update that takes place. (In practice, an update to an index entry consists of performing a delete followed by a re-insert, but the physicalities don't change the principle: "rows" in an index must be allowed to move if their value changes; rows in a table don't move, whatever happens to their values)
An IOT is, at the end of the day, simply an index with a lot more columns in it than a "normal" index would have -so it, too, has to allow its entires (its 'rows', if you like) to move. Therefore, an IOT cannot use a standard ROWID, which is assigned once and forever. Instead, it has to use something which takes account of the fact that its rows might wander. That is the logical rowid. It's no more "physical" than a physical rowid -neither are physically stored anywhere. But a 'physical' rowid is invariant; a logical one is not. The logical one is actually constructed in part from the primary key of the IOT -and that's the main reason why you cannot ever get rid of the primary key constraint on the IOT. Being allowed to do so would equate to allowing you to destroy the one organising principle for its contents that an IOT possesses.
(See the section entitled "The ROWID Pseudocolumn" and following on this page: http://download.oracle.com/docs/cd/B28359_01/server.111/b28318/datatype.htm#CNCPT1845
So IOTs have their data stored in them in primary key order. But they don't just contain the primary key, but every other column in the 'table definition' too. Therefore, just like with an ordinary table, you might want sometimes to search for data on columns which are NOT part of the primary key -and in that case, you might well want these non-primary key columns to be indexed. Therefore, you will create ordinary indexes on these columns -at this point, you're creating an index on an index, really, but that's a side issue, too! These extra indexes are called 'secondary indexes', simply because they are 'subsidiary indexes' to the main one, which is the "table" itself arranged in primary key order.
Finally, a leaf block split is simply what happens when you have to make room for new data in an index block which is already packed to the rafters with existing data. Imagine an index block can only contain four entries, for example. You fill it with entries for Adam, Bob, Charlie, David. You now insert a new record for 'Brian'. If this was a table, you could throw Brian into any new block you like: data in a table has no positional significance. But entries in an index MUST have positional significance: you can't just throw Brian in amongst the middle of a lot of Roberts, Susans and Tanyas. Brian HAS to go in between the existing entires for Bob and Charlie. Yet you can't just put him in the middle of those two, because then you'd have five entries in a block, not four, which we imagined for the moment to be the maximum allowed. So what to do? What you do is: obtain a new, empty block. Move Charlie and David's entries into the new block. Now you have two blocks: Adam-Bob and Charlie-David. Each only has two entries, so each has two 'spaces' to accept new entries. Now you have room to add in the entry for Brian... and so you end up with Adam-Bob-Brian and Charlie-David.
The process of moving some index entries out of one block into a new one so that there's room to allow new entries to be inserted in the middle of existing ones is called a block split. They happen for other reasons, too, so this is just a gloss treatment of them, but they give you the basic idea. It's because of block splits that indexes (and hence IOTs) see their "rows" move: Charlie and David started in one block and ended up in a completely different block because of a new (and completely unrelated to them) insert.
Very finally, overflow is simply a way of splitting off data into a separate table segment that wouldn't sensibly be stored in the main IOT segment itself. Suppose you create an IOT containing four columns: one, a numeric sequence number; two, a varchar2(10); three, a varchar2(15); and four, a blob. Column 1 is the primary key.
The first three columns are small and relatively compact. The fourth column is a blob data type -so it could be storing entire DVD movies, multi-gigabyte-sized monsters. Do you really want your index segment (for that is what an IOT really is) to balloon to huge sizes every time you add a new row? Probably not. You probably want columns 1 to 3 stored in the IOT, but column 4 can be bumped off over to some segment on its own (the overflow segment, in fact), and a link (actually, a physical rowid pointer) can link from the one to the other. Left to its own devices, an IOT will chop off every column after the primary key one when a record which threatens to consume more than 50% of a block gets inserted. However, to keep the main IOT small and compact and yet still contain non-primary key data, you can alter these default settings. INCLUDE, for example, allows you to specify which last non-primary key column should be the point at which a record is divided between 'keep in IOT' and 'move out to overflow segment'. You might say 'INCLUDE COL3' in the earlier example, so that COL1, COL2 and COL3 stay in the IOT and only COL4 overflows. And PCTTHRESHOLD can be set to, say, 5 or 10 so that you try to ensure an IOT block always contains 10 to 20 records -instead of the 2 you'd end up with if the default 50% kicked in. -
Hi,
We have created an index(assume z2) on table CATSDB with 2 fields. There is an other index(Z1 assume) with the same fields and the order is also same. When a report accesing the table it is taking more time to run when index Z2 is on table. But when deleted then the report ran quickly. Is it with the duplicate index created???
Please let me know
Regards
ShivaHi
i am giving total index and buffering concept details by seeing this you can understand how we can achive performance through these
<b>reward if usefull</b>
<b>Performance during table access</b>
<b>Indexes</b>
Primary and secondary indexes
Structure of an index
Accessing tables using indexes
<b>Table buffering</b>
Advantages of buffering
Concept of buffering
Buffering types
Buffer synchronization
<b>Primary and secondary indexes</b>
Index: Technical key of a database table.
Primary index: The primary index contains the key fields of the table and a pointer to the non-key fields of the table. The primary index is created automatically when the table is created in the database.
Secondary index: Additional indexes could be created considering the most frequently accessed dimensions of the table.
<b>Structure of an Index</b>
An index can be used to speed up the selection of data records from a table.
An index can be considered to be a copy of a database table reduced to certain fields. The data is stored in sorted form in this copy. This sorting permits fast access to the records of the table (for example using a binary search). Not all of the fields of the table are contained in the index. The index also contains a pointer from the index entry to the corresponding table entry to permit all the field contents to be read.
When creating indexes, please note that:
An index can only be used up to the last specified field in the selection! The fields which are specified in the WHERE clause for a large number of selections should be in the first position.
Only those fields whose values significantly restrict the amount of data are meaningful in an index.
When you change a data record of a table, you must adjust the index sorting. Tables whose contents are frequently changed therefore should not have too many indexes.
Make sure that the indexes on a table are as disjunctive as possible.
(That is they should contain as few fields in common as possible. If two indexes on a table have a large number of common fields, this could make it more difficult for the optimizer to choose the most selective index.)
<b>Accessing tables using Indexes</b>
The database optimizer decides which index on the table should be used by the database to access data records.
You must distinguish between the primary index and secondary indexes of a table. The primary index contains the key fields of the table. The primary index is automatically created in the database when the table is activated. If a large table is frequently accessed such that it is not possible to apply primary index sorting, you should create secondary indexes for the table.
The indexes on a table have a three-character index ID. '0' is reserved for the primary index. Customers can create their own indexes on SAP tables; their IDs must begin with Y or Z.
If the index fields have key function, i.e. they already uniquely identify each record of the table, an index can be called a unique index. This ensures that there are no duplicate index fields in the database.
When you define a secondary index in the ABAP Dictionary, you can specify whether it should be created on the database when it is activated. Some indexes only result in a gain in performance for certain database systems. You can therefore specify a list of database systems when you define an index. The index is then only created on the specified database systems when activated
<b>Database access using Buffer concept</b>
Buffering allows you to access data quicker by letting you
access it from the application server instead of the database.
<b>Advantages of buffering</b>
Table buffering increases the performance when the records of the table are read.
As records of a buffered table are read directly from the local buffer of the application server on which the accessing transaction is running, time required to access data is greatly reduced. The access improves by a factor of 10 to 100 depending on the structure of the table and on the exact system configuration.
If the storage requirements in the buffer increase due to further data, the data that has not been accessed for the longest time is displaced. This displacement takes place asynchronously at certain times which are defined dynamically based on the buffer accesses. Data is only displaced if the free space in the buffer is less than a predefined value or the quality of the access is not satisfactory at this time.
Entering $TAB in the command field resets the table buffers on the corresponding application server. Only use this command if there are inconsistencies in the buffer. In large systems, it can take several hours to fill the buffers. The performance is considerably reduced during this time.
<b>Concept of buffering</b>
The R/3 System manages and synchronizes the buffers on the individual application servers. If an application program accesses data of a table, the database interfaces determines whether this data lies in the buffer of the application server. If this is the case, the data is read directly from the buffer. If the data is not in the buffer of the application server, it is read from the database and loaded into the buffer. The buffer can therefore satisfy the next access to this data.
The buffering type determines which records of the table are loaded into the buffer of the application server when a record of the table is accessed. There are three different buffering types.
With full buffering, all the table records are loaded into the buffer when one record of the table is accessed.
With generic buffering, all the records whose left-justified part of the key is the same are loaded into the buffer when a table record is accessed.
With single-record buffering, only the record that was accessed is loaded into the buffer.
<b>Buffering types</b>
With full buffering, the table is either completely or not at all in the buffer. When a record of the table is accessed, all the records of the table are loaded into the buffer.
When you decide whether a table should be fully buffered, you must take the table size, the number of read accesses and the number of write accesses into consideration. The smaller the table is, the more frequently it is read and the less frequently it is written, the better it is to fully buffer the table.
Full buffering is also advisable for tables having frequent accesses to records that do not exist. Since all the records of the table reside in the buffer, it is already clear in the buffer whether or not a record exists.
The data records are stored in the buffer sorted by table key. When you access the data with SELECT, only fields up to the last specified key field can be used for the access. The left-justified part of the key should therefore be as large as possible for such accesses. For example, if the first key field is not defined, the entire table is scanned in the buffer. Under these circumstances, a direct access to the database could be more efficient if there is a suitable secondary index there.
With generic buffering, all the records whose generic key fields agree with this record are loaded into the buffer when one record of the table is accessed. The generic key is a left-justified part of the primary key of the table that must be defined when the buffering type is selected. The generic key should be selected so that the generic areas are not too small, which would result in too many generic areas. If there are only a few records for each generic area, full buffering is usually preferable for the table. If you choose too large a generic key, too much data will be invalidated if there are changes to table entries, which would have a negative effect on the performance.
A table should be generically buffered if only certain generic areas of the table are usually needed for processing.
Client-dependent, fully buffered tables are automatically generically buffered. The client field is the generic key. It is assumed that not all of the clients are being processed at the same time on one application server. Language-dependent tables are a further example of generic buffering. The generic key includes all the key fields up to and including the language field.
The generic areas are managed in the buffer as independent objects. The generic areas are managed analogously to fully buffered tables. You should therefore also read the information about full buffering.
Single-record buffering is recommended particularly for large tables in which only a few records are accessed repeatedly with SELECT SINGLE. All the accesses to the table that do not use SELECT SINGLE bypass the buffer and directly access the database.
If you access a record that was not yet buffered using SELECT SINGLE, there is a database access to load the record. If the table does not contain a record with the specified key, this record is recorded in the buffer as non-existent. This prevents a further database access if you make another access with the same key
You only need one database access to load a table with full buffering, but you need several database accesses with single-record buffering. Full buffering is therefore generally preferable for small tables that are frequently accessed.
<b>Synchronizing local buffers</b>
The table buffers reside locally on each application server in the system. However, this makes it necessary for the buffer administration to transfer all changes made to buffered objects to all the application servers of the system.
If a buffered table is modified, it is updated synchronously in the buffer of the application server from which the change was made. The buffers of the whole network, that is, the buffers of all the other application servers, are synchronized with an asynchronous procedure.
Entries are written in a central database table (DDLOG) after each table modification that could be buffered. Each application server reads these entries at fixed time intervals.
If entries are found that show a change to the data buffered by this server, this data is invalidated. If this data is accessed again, it is read directly from the database. In such an access, the table can then be loaded to the buffer again. -
Is Index organization tables better in performance compare to normal tables
Hi,
i am using oracle 10g and my domain is on telecom.
my requirement is when 'A' party calls 'B' Party based on 'B' party number
we have to find which area the call lands based on that tariff will be applied
but the data configured in Area table is not the complete number its just a CC+NDC(4or5 digits in length)
so i have to find which one matches the nearest to 'B' party number.
i uses the following query
select max(area_code)
from ZONE_AREA
where '9888123456' like AREA_CODE||'%'
and network_id=1;
this is the structure of the table
create table ZONE_AREA(
AREA_CODE VARCHAR2(20),
AREA_NAME VARCHAR2(30) not null,
ZONE_CODE VARCHAR2(10) not null,
CALL_TYPE VARCHAR2(1) not null,
NETWORK_ID NUMBER(2),
primary key (NETWORK_ID, AREA_CODE))
the table contains around 200000 rows.
the data in table look like
AREA_CODE
98812
90020
900
9732
the hit ratio for the above query is massive since it fires for every call but my DBA complaining me
this query utilizes more CPU need to be tuned.
i thought of going for Index organization tables since i never used this but want to give a try to see any improvisation is there
Hence i created the Index organization table(IOT) for the same above structure in my development environment
with 60,000 rows in it.
create table ZONE_AREA_IOT
AREA_CODE VARCHAR2(20),
AREA_NAME VARCHAR2(30) not null,
ZONE_CODE VARCHAR2(10) not null,
CALL_TYPE VARCHAR2(1) not null,
NETWORK_ID NUMBER(2),
CONSTRAINT pk_admin_docindex1 PRIMARY KEY (NETWORK_ID, AREA_CODE))
ORGANIZATION INDEX
also the plain table (ZONE_AREA) have 60,000 rows in my development server.
now i fired the query on my plain table
select max(area_code)
from ZONE_AREA
where '9888123456' like AREA_CODE||'%'
and network_id=1;
the following is the execution plan
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 1 | 11 | 3 (34)| 00:00:01 |
| 1 | SORT AGGREGATE | | 1 | 11 | | |
| 2 | FIRST ROW | | 1 | 11 | 3 (34)| 00:00:01 |
|* 3 | INDEX RANGE SCAN (MIN/MAX)| SYS_C007738 | 1 | 11 | 3 (34)| 00:00:01 |
now i fired the query on the newly created IOT table
select max(area_code)
from ZONE_AREA_IOT
where '9888123456' like AREA_CODE||'%'
and network_id=1;
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 1 | 25 | 2 (0)| 00:00:01 |
| 1 | SORT AGGREGATE | | 1 | 25 | | |
| 2 | FIRST ROW | | 21 | 525 | 2 (0)| 00:00:01 |
|* 3 | INDEX RANGE SCAN (MIN/MAX)| PK_ADMIN_DOCINDEX1 | 21 | 525 | 2 (0)| 00:00:01 |
both tables have similar record count
but the plans differ don't under stand the Rows column in the above plans for normal table its shows 11 bytes
for IOT table it shows 525 bytes why this difference ?
also CPU cost shows 3 in normal table and for IOT it shows 2
for the above scenario is IOT table is advisable will it cut down the CPU cost is any overheads there for using IOT
please respond
regards
naveenI think you are deviating from the real problem.
I'm also in Telecom domain and what you are talking about is what is called "most matching" algorithm.
Practically suppose that party A calls party B and you want to know which is the tariff to apply.
Usually tariff tables are based on this "most matching" criteria where the correct tariff is the most matching with the called number.
Let me give you an example.
Suppose that I have a tariff table in this way:
WITH mytariff AS
SELECT '90123' destination, 1.5 tariff_per_min FROM DUAL UNION ALL
SELECT '9012' destination, 1.6 tariff_per_min FROM DUAL UNION ALL
SELECT '901' destination, 1.7 tariff_per_min FROM DUAL UNION ALL
SELECT '90' destination, 1.8 tariff_per_min FROM DUAL UNION ALL
SELECT '55123' destination, 1.0 tariff_per_min FROM DUAL UNION ALL
SELECT '5512' destination, 1.1 tariff_per_min FROM DUAL UNION ALL
SELECT '551' destination, 1.2 tariff_per_min FROM DUAL UNION ALL
SELECT '55' destination, 1.3 tariff_per_min FROM DUAL
SELECT * FROM mytariff;
DESTINATION TARIFF_PER_MIN
90123 1.5
9012 1.6
901 1.7
90 1.8
55123 1
5512 1.1
551 1.2
55 1.3
{code}
Correct me if I'm wrong:
{code}
if party A dials 901234567 then it will match destination 90123 and tariff_per_min 1.5
if party A dials 901244567 then it will match destination 9012 and tariff_per_min 1.6
if party A dials 901344567 then it will match destination 901 and tariff_per_min 1.6
if party A dials 551244567 then it will match destination 5512 and tariff_per_min 1.1
etc.
{code}
Confirm if this is your criteria in finding the tariff.
The billing/rating systems I know usually store this information in database tables but the rating engine (generally a c++ program in Unix) is normally reading this information once, putting them in memory and rating the calls by reading information in memory.
I'm not saying that this is the only approach but it seems the most used.
In your case, It looks that you are using to do the same thing SQL or PL/SQL and definitely I understand that applying this algorithm by reading the tariff table for each call records is going to affect your performances heavily.
I have a couple of questions for your:
1) Are you using a SQL statement or a PL/SQL procedure to rate your calls?
2) Could you show us how you assign the tariff to your calls?
I don't think using IOT will solve your problem. IOT has the advantage to read the data together with the index and it is suitable especially if you read your data always with a certain key.
If your data about tariff is static, or doesn't change so often, which I suppose it the case, you could consider a different approach like loading them in a collection in PL/SQL and them retrieving them from collection. It might not be the optimal solution but it is worth considering it.
In order to evaluate your problem please give the details mentioned above.
Regards.
Al -
HI,
Please give me the link of t-code of sales order table no & item table no.
Thanks,
Rajesh.Hi,
There are three main tables comes insales order.
1) header table - vbak
2) item table - vbap
3) Schedule lin e table- vbep
Some other sales related are as follows:-
SALES RELATED TABLES
VBSK Collective Processing for a Sales Documen
VBSN Change status relating to scheduling agre
VBSP SD Document Item for Models of Material S
VBSS Collective Processing: Sales Documents
VBUK Sales Document: Header Status and Adminis
VBUP Sales Document: Item Status
VBRK Billing Document: Header Data
VBRL Sales Document: Invoice List
VBRP Billing Document: Item Data
VBAG Sales Document: Release Data by Schedule lines
VBAK Sales Document: Header Data
VBAP Sales Document: Item Data
VBBE Sales Requirements: Individual Records
VBBPA Sales Document: Partner
VBBS Sales Requirement Totals Record
VBEH Schedule line history
VBEP Sales Document: Schedule Line Data
VBFA Sales Document Flow
VBFS Error Log for Collective Processing
VBHDR Update header
VBKA Sales Activities
VBKD Sales Document: Business Data
VBKK SD Doc.Export Letter of Credit
VBKOF SD index: Open sales activities by partne
VBKPA SD index: Sales activities by partner fun
VBKPF Document Header for Document Parking
VBLB Sales document: Release order data
VBLK SD Document: Delivery Note Header
VBMOD Update function modules
VBMUE Sales Document: Characteristic Overview
VBMUET Sales Document: Characteristic Overview D
VBMUEZ Sales Document: Characteristic Overview A
VBOX SD Document: Billing Document: Rebate Ind
VBPA Sales Document: Partner
VBPA2 Sales document: Partner (used several tim
VBPA3 Tax Numbers for One-Time Customers
VBPK Sales Document: Product Proposal Header
VBPM Supplement for Sales Document Items: Tech
VBPV Sales Document: Product Proposal
VBREF SD Object Link to Item References -
Field catalog & internal table are not mutually convertible
Hi friends,
         please help me for this problem, actually i m trying to display three alv reports from the three buttond i have given on my first basic report. its working fine till first & getting the data into the internal table for the second also. but when coming to the field catalog for the second report its giving syntax error as my "field catalog and internal table are not mutually convertible'".i have tried by giving different fieldcatalog also but its giving the same problem.please help for this & try to give an example if u can. Thanks a lot.
Regards
PankajThis is my code :
TABLES: PLAF,
MARA,
MAKT,
AFPO,
T023T,
VSAUFK,
T006A,
MBEW,
ZCDR_D.
Type Pools for ALV *************************
TYPE-POOLS: SLIS,
ABAP.
KKBLO.
DATA DECLARATION. ****************************
DATA: FLAG TYPE I,
FLAG1 TYPE I,
FLAG2 TYPE I,
FLAG3 TYPE I,
FLAG4 TYPE I,
FLAG5 TYPE I.
********Declaration for field catalog
DATA: LAYOUT TYPE SLIS_LAYOUT_ALV,
IT_FIELDCAT TYPE SLIS_T_FIELDCAT_ALV,
IT_SORT TYPE SLIS_T_SORTINFO_ALV,
WA_SORT TYPE SLIS_SORTINFO_ALV,
WA_SUBT LIKE SLIS_EV_SUBTOTAL_TEXT,
IT_EVENTS TYPE TABLE OF slis_alv_event WITH NON-UNIQUE DEFAULT KEY
WITH HEADER LINE INITIAL SIZE 0,
WA_FIELDCAT TYPE SLIS_FIELDCAT_ALV,
LAYOUT1 TYPE SLIS_LAYOUT_ALV,
IT_FIELDCAT1 TYPE SLIS_T_FIELDCAT_ALV,
IT_SORT TYPE SLIS_T_SORTINFO_ALV,
WA_SORT TYPE SLIS_SORTINFO_ALV,
WA_SUBT LIKE SLIS_EV_SUBTOTAL_TEXT,
IT_EVENTS TYPE TABLE OF slis_alv_event WITH NON-UNIQUE DEFAULT KEY
WITH HEADER LINE INITIAL SIZE 0,
WA_FIELDCAT1 TYPE SLIS_FIELDCAT_ALV,
LAYOUT2 TYPE SLIS_LAYOUT_ALV,
IT_FIELDCAT2 TYPE SLIS_T_FIELDCAT_ALV,
IT_SORT TYPE SLIS_T_SORTINFO_ALV,
WA_SORT TYPE SLIS_SORTINFO_ALV,
WA_SUBT LIKE SLIS_EV_SUBTOTAL_TEXT,
IT_EVENTS TYPE TABLE OF slis_alv_event WITH NON-UNIQUE DEFAULT KEY
WITH HEADER LINE INITIAL SIZE 0,
WA_FIELDCAT2 TYPE SLIS_FIELDCAT_ALV,
LAYOUT3 TYPE SLIS_LAYOUT_ALV,
IT_FIELDCAT3 TYPE SLIS_T_FIELDCAT_ALV,
IT_SORT TYPE SLIS_T_SORTINFO_ALV,
WA_SORT TYPE SLIS_SORTINFO_ALV,
WA_SUBT LIKE SLIS_EV_SUBTOTAL_TEXT,
IT_EVENTS TYPE TABLE OF slis_alv_event WITH NON-UNIQUE DEFAULT KEY
WITH HEADER LINE INITIAL SIZE 0,
WA_FIELDCAT3 TYPE SLIS_FIELDCAT_ALV.
TYPES DECLARATION. ****************************
TYPES: BEGIN OF TY_MARA,
MATNR LIKE MARA-MATNR, " Material Number
MATKL LIKE MARA-MATKL, " Material Group
END OF TY_MARA.
TYPES: BEGIN OF TY_PLAF,
PERTR LIKE PLAF-PERTR, " Date
PLNUM LIKE PLAF-PLNUM, " Planned Order Number
MATNR LIKE PLAF-MATNR, " Material number
PLWRK LIKE PLAF-PLWRK, " Plant
KDAUF LIKE PLAF-KDAUF, " Sales Order Number
KDPOS LIKE PLAF-KDPOS, " SO Line Item
END OF TY_PLAF.
TYPES: BEGIN OF TY_MAKT,
MATNR LIKE PLAF-MATNR, " Material Number
MAKTX LIKE MAKT-MAKTX, " Material Description
END OF TY_MAKT.
TYPES: BEGIN OF TY_AFPO,
PLNUM LIKE AFPO-PLNUM, " Planned Order Number
MATNR LIKE AFPO-MATNR, " Material Number
KDAUF LIKE AFPO-KDAUF, " Sales Order Number
KDPOS LIKE AFPO-KDPOS, " SO Line Item
AUFNR LIKE AFPO-AUFNR, " Production Order
STRMP LIKE AFPO-STRMP,
DWERK LIKE AFPO-DWERK,
END OF TY_AFPO.
TYPES: BEGIN OF TY_ZCDR_D,
MANDT LIKE ZCDR_D-MANDT, " Client
CBNO LIKE ZCDR_D-CBNO, " Customs Book Number
PLNUM LIKE ZCDR_D-PLNUM, " Planned Order Number
MATNR LIKE ZCDR_D-MATNR, " Material Number
MAKTX LIKE ZCDR_D-MAKTX, " Material Description
KDAUF like ZCDR_D-KDAUF, " Sales Order Number
KDPOS like ZCDR_D-KDPOS, " SO Line Item
AUFNR LIKE ZCDR_D-AUFNR, " Production Order
END OF TY_ZCDR_D.
TYPES: BEGIN OF TY_VSAUFK,
INACT LIKE VSAUFK-INACT, " Status Indicator
END OF TY_VSAUFK.
TYPES: BEGIN OF TY_PLAF_MAKT,
CBNO LIKE ZCDR_D-CBNO, " Customs Book Number
PLNUM LIKE PLAF-PLNUM, " Planned Order Number
CHK TYPE C, " Check Box
MATNR LIKE PLAF-MATNR, " Material Number
MAKTX LIKE MAKT-MAKTX, " Material Description
KDAUF LIKE PLAF-KDAUF, " Sales Order Number
KDPOS LIKE PLAF-KDPOS, " SO Line Item
AUFNR LIKE AFPO-AUFNR, " Production Order
END OF TY_PLAF_MAKT.
TYPES: BEGIN OF TY_HELP_ITEM,
CBNO TYPE ZCDR_D-CBNO, " Customs Book Number
PLNUM LIKE ZCDR_D-PLNUM, " Planned Order Number
MATNR LIKE ZCDR_D-MATNR, " Material Number
MAKTX LIKE ZCDR_D-MAKTX, " Material Description
KDAUF LIKE ZCDR_D-KDAUF, " Sales Order Number
KDPOS LIKE ZCDR_D-KDPOS, " SO Line Item
AUFNR LIKE ZCDR_D-AUFNR, " Production Order
END OF TY_HELP_ITEM.
WORK AREA ******************************
DATA: WA_MARA TYPE TY_MARA,
WA_PLAF TYPE TY_PLAF,
WA_MAKT TYPE TY_MAKT,
WA_AFPO TYPE TY_AFPO,
WA_ZCDR_D TYPE TY_ZCDR_D,
WA_VSAUFK TYPE TY_VSAUFK,
WA_PLAF_MAKT TYPE TY_PLAF_MAKT,
WA_HELP_ITEM TYPE TY_HELP_ITEM.
INTERNAL TABLES ****************************
DATA: IT_MARA TYPE TABLE OF TY_MARA,
IT_PLAF TYPE TABLE OF TY_PLAF,
IT_MAKT TYPE TABLE OF TY_MAKT,
IT_AFPO TYPE TABLE OF TY_AFPO,
IT_ZCDR_D TYPE TABLE OF TY_ZCDR_D,
IT_VSAUFK TYPE TABLE OF TY_VSAUFK,
IT_PLAF_MAKT TYPE TABLE OF TY_PLAF_MAKT,
IT_HELP_ITEM TYPE TABLE OF TY_HELP_ITEM.
*it_events TYPE TABLE OF slis_alv_event WITH NON-UNIQUE DEFAULT KEY
*WITH HEADER LINE INITIAL SIZE 0.
TYPES: BEGIN OF TY_BOM,
MATMK LIKE STPOX-MATMK,
MTNRV LIKE ZCDR_D-MATNR,
IDNRK LIKE STPOX-IDNRK,
MNGLG LIKE STPOX-MNGLG,
MMEIN LIKE STPOX-MMEIN,
VPRSV LIKE STPOX-VPRSV,
UPRICE LIKE MBEW-STPRS,
TPRICE LIKE MBEW-STPRS,
END OF TY_BOM,
BEGIN OF TY_QUAN,
MATMK LIKE STPOX-MATMK,
MTNRV LIKE ZCDR_D-MATNR,
IDNRK LIKE STPOX-IDNRK,
MNGLG LIKE STPOX-MNGLG,
MMEIN LIKE STPOX-MMEIN,
UPRICE LIKE MBEW-STPRS,
TPRICE LIKE MBEW-STPRS,
END OF TY_QUAN,
BEGIN OF TY_T023T,
MATKL LIKE T023T-MATKL,
WGBEZ LIKE T023T-WGBEZ,
END OF TY_T023T,
BEGIN OF TY_T006A,
MMEIN LIKE T006A-MSEHI,
MSEHT LIKE T006A-MSEHT,
END OF TY_T006A,
BEGIN OF TY_IMP_FINAL,
SNO TYPE SY-INDEX,
HSCODE LIKE ZHSCODE-HSCODE,
WGBEZ TYPE T023T-WGBEZ,
SPEC(20) TYPE C,
MNGLG LIKE STPOX-MNGLG,
MSEHT LIKE T006A-MSEHT,
CNTRY(13) TYPE C,
UPRICE TYPE P LENGTH 16 DECIMALS 2,
TPRICE TYPE P LENGTH 16 DECIMALS 2,
CURRCODE TYPE C LENGTH 5,
END OF TY_IMP_FINAL,
BEGIN OF TY_MBEW,
MATNR LIKE MBEW-MATNR,
VPRSV LIKE MBEW-VPRSV,
STPRS LIKE MBEW-STPRS,
VERPR LIKE MBEW-VERPR,
END OF TY_MBEW.
DATA: WA_BOM TYPE TY_BOM,
WA_QUAN TYPE TY_QUAN,
WA_IMP_FINAL TYPE TY_IMP_FINAL,
WA_T023T TYPE TY_T023T,
WA_T006A TYPE TY_T006A,
WA_MBEW TYPE TY_MBEW.
DATA: IT_BOM TYPE TABLE OF TY_BOM,
IT_QUAN TYPE TABLE OF TY_QUAN,
IT_IMP_FINAL TYPE TABLE OF TY_IMP_FINAL,
IT_MBEW TYPE TABLE OF TY_MBEW.
SELECTION-SCREEN **************************
SELECTION-SCREEN BEGIN OF BLOCK b1 WITH FRAME TITLE TEXT-001.
PARAMETERS : PR_CBNO LIKE ZCDR_D-CBNO OBLIGATORY. "Customs Book number
SELECTION-SCREEN END OF BLOCK b1.
INITIALIZATION **************************
INITIALIZATION.
**PERFORM CLEAR_DATA.
**CLEAR: wa_layout.
*PERFORM set_events USING it_events[].
SELECT OPTION ****************************************
SELECTION-SCREEN : BEGIN OF BLOCK BLK WITH FRAME TITLE TEXT-002.
SELECTION-SCREEN SKIP 1.
SELECT-OPTIONS:
SO_PERTR for PLAF-PERTR, "----
Date
SO_MATNR for MARA-MATNR, "----
Material
SO_MATKL for MARA-MATKL, "----
Material Group
SO_PLWRK for PLAF-PLWRK OBLIGATORY, "----
Plant
SO_KDAUF for PLAF-KDAUF. "----
Sales Order
SELECTION-SCREEN : END OF BLOCK BLK.
SELECTION SCREEN F4 HELP *********************
AT SELECTION-SCREEN ON VALUE-REQUEST FOR PR_CBNO.
DATA: DYNFIELDS TYPE TABLE OF DYNPREAD WITH HEADER LINE.
DYNFIELDS-FIELDNAME = PR_CBNO.
APPEND DYNFIELDS.
CALL FUNCTION 'DYNP_VALUES_READ'
EXPORTING
DYNAME = SY-CPROG
DYNUMB = SY-DYNNR
TRANSLATE_TO_UPPER = 'X'
REQUEST = ' '
PERFORM_CONVERSION_EXITS = ' '
PERFORM_INPUT_CONVERSION = ' '
DETERMINE_LOOP_INDEX = ' '
START_SEARCH_IN_CURRENT_SCREEN = ' '
START_SEARCH_IN_MAIN_SCREEN = ' '
START_SEARCH_IN_STACKED_SCREEN = ' '
START_SEARCH_ON_SCR_STACKPOS = ' '
SEARCH_OWN_SUBSCREENS_FIRST = ' '
SEARCHPATH_OF_SUBSCREEN_AREAS = ' '
TABLES
DYNPFIELDS = DYNFIELDS
EXCEPTIONS
INVALID_ABAPWORKAREA = 1
INVALID_DYNPROFIELD = 2
INVALID_DYNPRONAME = 3
INVALID_DYNPRONUMMER = 4
INVALID_REQUEST = 5
NO_FIELDDESCRIPTION = 6
INVALID_PARAMETER = 7
UNDEFIND_ERROR = 8
DOUBLE_CONVERSION = 9
STEPL_NOT_FOUND = 10
OTHERS = 11
IF SY-SUBRC <> 0.
MESSAGE ID SY-MSGID TYPE SY-MSGTY NUMBER SY-MSGNO
WITH SY-MSGV1 SY-MSGV2 SY-MSGV3 SY-MSGV4.
ENDIF.
READ TABLE DYNFIELDS WITH KEY FIELDNAME = 'CBNO'.
PR_CBNO = DYNFIELDS-FIELDVALUE.
SELECT
CBNO
PLNUM
MATNR
MAKTX
KDAUF
KDPOS
AUFNR
FROM ZCDR_D
INTO TABLE IT_HELP_ITEM .
CALL FUNCTION 'F4IF_INT_TABLE_VALUE_REQUEST'
EXPORTING
DDIC_STRUCTURE = ' '
RETFIELD = 'CBNO'
PVALKEY = ' '
DYNPPROG = SY-CPROG
DYNPNR = SY-DYNNR
DYNPROFIELD = 'PR_CBNO'
STEPL = 0
WINDOW_TITLE =
VALUE = ' '
VALUE_ORG = 'S'
MULTIPLE_CHOICE = ' '
DISPLAY = ' '
CALLBACK_PROGRAM = ' '
CALLBACK_FORM = ' '
MARK_TAB =
IMPORTING
USER_RESET =
TABLES
VALUE_TAB = IT_HELP_ITEM
FIELD_TAB =
RETURN_TAB =
DYNPFLD_MAPPING =
EXCEPTIONS
PARAMETER_ERROR = 1
NO_VALUES_FOUND = 2
OTHERS = 3
IF SY-SUBRC <> 0.
MESSAGE ID SY-MSGID TYPE SY-MSGTY NUMBER SY-MSGNO
WITH SY-MSGV1 SY-MSGV2 SY-MSGV3 SY-MSGV4.
ENDIF.
***********************SELECTION SCREEN VALIDATION.*******************
AT SELECTION-SCREEN ON PR_CBNO.
SELECT SINGLE *
FROM ZCDR_D
WHERE CBNO = PR_CBNO.
IF SY-SUBRC EQ 0.
MESSAGE E000(ZCBR) WITH PR_CBNO.
ENDIF.
AT SELECTION-SCREEN ON SO_PERTR.
IF SO_PERTR IS NOT INITIAL.
SELECT SINGLE *
FROM PLAF
WHERE PERTR IN SO_PERTR.
IF SY-SUBRC NE 0.
MESSAGE W001(ZCBR) WITH SO_PERTR-LOW.
ENDIF.
ENDIF.
AT SELECTION-SCREEN ON SO_MATNR.
IF SO_MATNR IS NOT INITIAL.
SELECT SINGLE *
FROM MARA
WHERE MATNR IN SO_MATNR.
IF SY-SUBRC NE 0.
MESSAGE W002(ZCBR) WITH SO_MATNR-LOW.
ENDIF.
ENDIF.
AT SELECTION-SCREEN ON SO_MATKL.
IF SO_MATKL IS NOT INITIAL.
SELECT SINGLE *
FROM MARA
WHERE MATKL IN SO_MATKL.
IF SY-SUBRC NE 0.
MESSAGE W003(ZCBR) WITH SO_MATKL-LOW.
ENDIF.
ENDIF.
AT SELECTION-SCREEN ON SO_PLWRK.
IF SO_PLWRK IS NOT INITIAL.
SELECT SINGLE * FROM PLAF
WHERE PLWRK IN SO_PLWRK.
IF SY-SUBRC NE 0.
MESSAGE W004(ZCBR) WITH SO_PLWRK-LOW.
ENDIF.
ENDIF.
AT SELECTION-SCREEN ON SO_KDAUF.
IF SO_KDAUF IS NOT INITIAL.
SELECT SINGLE * FROM PLAF
WHERE KDAUF IN SO_KDAUF.
IF SY-SUBRC NE 0.
MESSAGE W005(ZCBR) WITH SO_KDAUF-LOW.
ENDIF.
ENDIF.
*********************START-OF-SELECTION.*****************************
START-OF-SELECTION.
IF so_pertr IS NOT INITIAL.
FLAG = 1.
ENDIF.
IF SO_MATNR IS NOT INITIAL.
FLAG1 = 1.
ENDIF.
IF so_matkl IS NOT INITIAL.
FLAG2 = 1.
ENDIF.
IF so_plwrk IS NOT INITIAL.
FLAG3 = 1.
ENDIF.
IF so_kdauf IS NOT INITIAL.
FLAG4 = 1.
ENDIF.
Select data into its internal table from different database tables
SELECT
MATNR
MATKL
MTART
INTO CORRESPONDING FIELDS OF TABLE IT_MARA
FROM MARA
WHERE MTART = 'ZFGS'.
IF FLAG2 NE 0.
DELETE IT_MARA WHERE
NOT ( MATKL IN SO_MATKL )
ENDIF.
IF FLAG1 NE 0.
DELETE IT_MARA WHERE
NOT ( MATNR IN SO_MATNR )
ENDIF.
SELECT
PERTR
PLNUM
MATNR
PLWRK
KDAUF
KDPOS
FROM PLAF
INTO CORRESPONDING FIELDS OF TABLE IT_PLAF
FOR ALL ENTRIES IN IT_MARA
WHERE PLWRK IN SO_PLWRK
AND MATNR = IT_MARA-MATNR.
SELECT
MATNR
PLNUM
AUFNR
KDAUF
KDPOS
STRMP
DWERK
INACT
FROM AFPO
INTO CORRESPONDING FIELDS OF TABLE IT_AFPO
FOR ALL ENTRIES IN IT_MARA
WHERE DWERK IN SO_PLWRK
AND MATNR = IT_MARA-MATNR.
WHERE MATNR = IT_MARA-MATNR
AND STRMP = IT_PLAF-PERTR
AND KDAUF = IT_PLAF-KDAUF
AND DWERK = IT_PLAF-PLWRK.
End of Data selection
Keep only those records which the user wants from his selection screen
IF FLAG NE 0.
DELETE IT_PLAF WHERE
NOT ( PERTR IN SO_PERTR )
DELETE IT_AFPO WHERE
NOT ( STRMP IN SO_PERTR )
ENDIF.
IF FLAG3 NE 0.
DELETE IT_PLAF WHERE
NOT ( PLWRK IN SO_PLWRK )
DELETE IT_AFPO WHERE
NOT ( DWERK IN SO_PLWRK )
ENDIF.
IF FLAG4 NE 0.
DELETE IT_PLAF WHERE
NOT ( KDAUF IN SO_KDAUF )
DELETE IT_AFPO WHERE
NOT ( KDAUF IN SO_KDAUF )
ENDIF.
SELECT
MATNR
MAKTX
FROM MAKT
INTO CORRESPONDING FIELDS OF TABLE IT_MAKT
FOR ALL ENTRIES IN IT_PLAF
WHERE MATNR = IT_PLAF-MATNR
AND SPRAS = 'EN'.
SELECT
FROM ZCDR_D
INTO TABLE IT_ZCDR_D.
Put data into final internal table from different internal tables
LOOP AT IT_MARA INTO WA_MARA.
LOOP AT IT_PLAF INTO WA_PLAF WHERE MATNR = WA_MARA-MATNR.
READ TABLE IT_ZCDR_D
INTO WA_ZCDR_D
WITH KEY PLNUM = WA_PLAF-PLNUM.
IF SY-SUBRC <> 0.
MOVE WA_PLAF-PLNUM TO WA_PLAF_MAKT-PLNUM.
MOVE WA_PLAF-MATNR TO WA_PLAF_MAKT-MATNR.
MOVE WA_PLAF-KDAUF TO WA_PLAF_MAKT-KDAUF.
MOVE WA_PLAF-KDPOS TO WA_PLAF_MAKT-KDPOS.
READ TABLE IT_AFPO INTO WA_AFPO WITH KEY PLNUM = WA_PLAF-PLNUM.
MOVE WA_AFPO-AUFNR TO WA_PLAF_MAKT-AUFNR.
SELECT
SINGLE * FROM VSAUFK
INTO TABLE IT_VSAUFK
WHERE AUFNR = WA_AFPO-AUFNR
AND STAT = 'I0012'.
IF SY-SUBRC <> 0.
MOVE WA_AFPO-AUFNR TO IT_PLAF_MAKT-AUFNR.
ELSE.
CHECK IT_VSAUFK-INACT = 'X'.
MOVE WA_AFPO-AUFNR TO IT_PLAF_MAKT-AUFNR.
ENDIF.
ENDLOOP.
READ TABLE IT_MAKT
INTO WA_MAKT
WITH KEY MATNR = WA_MARA-MATNR.
MOVE WA_MAKT-MAKTX TO WA_PLAF_MAKT-MAKTX.
APPEND WA_PLAF_MAKT TO IT_PLAF_MAKT.
CLEAR WA_PLAF_MAKT.
ENDIF.
ENDLOOP.
ENDLOOP.
LOOP AT IT_PLAF_MAKT .
LOOP AT IT_MARA INTO WA_MARA.
LOOP AT IT_PLAF INTO WA_PLAF WHERE MATNR = WA_MARA-MATNR.
LOOP AT IT_AFPO INTO WA_AFPO WHERE MATNR = WA_MARA-MATNR.
READ TABLE IT_ZCDR_D
INTO WA_ZCDR_D
WITH KEY PLNUM = WA_AFPO-PLNUM.
IF SY-SUBRC <> 0.
LOOP AT IT_AFPO INTO WA_AFPO.
WHERE MATNR IN SO_MATNR
AND STRMP = SO_PERTR
AND PLNUM IN SO_PLNUM
AND KDAUF IN SO_-KDAUF
AND MATKL IN SO_MATKL.
SELECT
SINGLE INACT FROM VSAUFK
INTO WA_VSAUFK
WHERE AUFNR = WA_AFPO-AUFNR
AND STAT = 'I0012'.
IF SY-SUBRC <> 0.
WA_PLAF_MAKT-PLNUM = WA_AFPO-PLNUM.
WA_PLAF_MAKT-KDAUF = WA_AFPO-KDAUF.
WA_PLAF_MAKT-KDPOS = WA_AFPO-KDPOS.
WA_PLAF_MAKT-MATNR = WA_AFPO-MATNR.
WA_PLAF_MAKT-AUFNR = WA_AFPO-AUFNR.
READ TABLE IT_MAKT INTO WA_MAKT WITH KEY MATNR = WA_AFPO-MATNR.
WA_PLAF_MAKT-MAKTX = WA_MAKT-MAKTX.
APPEND WA_PLAF_MAKT TO IT_PLAF_MAKT .
APPEND WA_AFPO TO IT_PLAF_MAKT.
MOVE WA_AFPO-AUFNR TO IT_PLAF_MAKT-AUFNR.
ELSE.
CHECK WA_VSAUFK-INACT = 'X'.
WA_PLAF_MAKT-PLNUM = WA_AFPO-PLNUM.
WA_PLAF_MAKT-KDAUF = WA_AFPO-KDAUF.
WA_PLAF_MAKT-KDPOS = WA_AFPO-KDPOS.
WA_PLAF_MAKT-MATNR = WA_AFPO-MATNR.
WA_PLAF_MAKT-AUFNR = WA_AFPO-AUFNR.
READ TABLE IT_MAKT INTO WA_MAKT WITH KEY MATNR = WA_AFPO-MATNR.
WA_PLAF_MAKT-MAKTX = WA_MAKT-MAKTX.
APPEND WA_PLAF_MAKT TO IT_PLAF_MAKT .
APPEND WA_AFPO TO IT_PLAF_MAKT.
MOVE WA_AFPO-AUFNR TO IT_PLAF_MAKT-AUFNR.
ENDIF.
ENDIF.
ENDLOOP.
EXIT.
ENDIF.
ENDLOOP.
ENDLOOP.
LOOP AT IT_PLAF_MAKT INTO WA_PLAF_MAKT.
WA_PLAF_MAKT-CBNO = PR_CBNO.
MODIFY IT_PLAF_MAKT FROM WA_PLAF_MAKT TRANSPORTING CBNO.
ENDLOOP.
ENDLOOP.
PERFORM CHANGE_CATALOG.
PERFORM ALV_DISPLAY.
*& Form CHANGE_CATALOG
text
FORM CHANGE_CATALOG.
LAYOUT-ZEBRA = 'X'.
DATA: L_POS TYPE I.
L_POS = L_POS + 1.
WA_FIELDCAT-col_pos = L_POS.
WA_FIELDCAT-SELTEXT_M = 'Planned Order Nos.'.
WA_FIELDCAT-TABNAME = WA_PLAF_MAKT.
WA_FIELDCAT-FIELDNAME = 'PLNUM'.
APPEND WA_FIELDCAT TO IT_FIELDCAT.
CLEAR WA_FIELDCAT.
L_POS = L_POS + 1.
WA_FIELDCAT-COL_POS = L_POS.
WA_FIELDCAT-INPUT = 'X'.
WA_FIELDCAT-SELTEXT_M = 'Check Box'.
WA_FIELDCAT-TABNAME = WA_PLAF_MAKT.
WA_FIELDCAT-CHECKBOX = 'X'.
WA_FIELDCAT-EDIT = abap_true.
WA_FIELDCAT-FIELDNAME = 'CHK'.
APPEND WA_FIELDCAT TO IT_FIELDCAT.
CLEAR WA_FIELDCAT.
L_POS = L_POS + 1.
WA_FIELDCAT-COL_POS = L_POS.
WA_FIELDCAT-OUTPUTLEN = '12'.
WA_FIELDCAT-SELTEXT_M = 'Material'.
WA_FIELDCAT-TABNAME = WA_PLAF_MAKT.
WA_FIELDCAT-FIELDNAME = 'MATNR'.
APPEND WA_FIELDCAT TO IT_FIELDCAT.
CLEAR WA_FIELDCAT.
L_POS = L_POS + 1.
WA_FIELDCAT-COL_POS = L_POS.
WA_FIELDCAT-OUTPUTLEN = '35'.
WA_FIELDCAT-SELTEXT_M = 'Material Description'.
WA_FIELDCAT-TABNAME = WA_PLAF_MAKT.
WA_FIELDCAT-FIELDNAME = 'MAKTX'.
APPEND WA_FIELDCAT TO IT_FIELDCAT.
CLEAR WA_FIELDCAT.
L_POS = L_POS + 1.
WA_FIELDCAT-COL_POS = L_POS.
WA_FIELDCAT-SELTEXT_M = 'Sales Order Number'.
WA_FIELDCAT-TABNAME = WA_PLAF_MAKT.
WA_FIELDCAT-FIELDNAME = 'KDAUF'.
APPEND WA_FIELDCAT TO IT_FIELDCAT.
CLEAR WA_FIELDCAT.
L_POS = L_POS + 1.
WA_FIELDCAT-COL_POS = L_POS.
WA_FIELDCAT-SELTEXT_M = 'S O Line Item'.
WA_FIELDCAT-TABNAME = WA_PLAF_MAKT.
WA_FIELDCAT-FIELDNAME = 'KDPOS'.
APPEND WA_FIELDCAT TO IT_FIELDCAT.
CLEAR WA_FIELDCAT.
L_POS = L_POS + 1.
WA_FIELDCAT-COL_POS = L_POS.
WA_FIELDCAT-OUTPUTLEN = '13'.
WA_FIELDCAT-SELTEXT_M = 'Production Order'.
WA_FIELDCAT-TABNAME = WA_PLAF_MAKT.
WA_FIELDCAT-FIELDNAME = 'AUFNR'.
APPEND WA_FIELDCAT TO IT_FIELDCAT.
CLEAR WA_FIELDCAT.
*GS_LAYOUT-TOTALS_BEFORE_ITEMS = 'X'.
*data : text like slis_ev_subtotal_text value 'total'.
*gs_layout-subtotals_text = text.
*gs_layout-totals_only = 'X'.
gs_layout-subtotals_text = 'total'.
endform. " CHANGE_CATALOG
*********************event*************************************
*& Form ALV_DISPLAY
text
FORM ALV_DISPLAY.
*data: LC_GLAY TYPE LVC_S_GLAY.
LC_GLAY-EDT_CLL_CB = 'X'.
gs_layout-colwidth_optimize = 'X'.
gs_layout-zebra = 'X'.
CALL FUNCTION 'REUSE_ALV_GRID_DISPLAY'
EXPORTING
I_INTERFACE_CHECK = ' '
I_BYPASSING_BUFFER = ' '
I_BUFFER_ACTIVE = ' '
I_CALLBACK_PROGRAM = SY-REPID
I_CALLBACK_PF_STATUS_SET = 'SET_PF_STATUS'
I_CALLBACK_USER_COMMAND = 'USER_COMMAND'
I_CALLBACK_TOP_OF_PAGE = ' '
I_CALLBACK_HTML_TOP_OF_PAGE = ' '
I_CALLBACK_HTML_END_OF_LIST = ' '
I_STRUCTURE_NAME =
I_BACKGROUND_ID = ' '
I_GRID_TITLE = 'PLANNED ORDERS'
I_GRID_SETTINGS = LC_GLAY
IS_LAYOUT = LAYOUT
IT_FIELDCAT = IT_FIELDCAT[]
IT_EXCLUDING =
IT_SPECIAL_GROUPS =
IT_SORT =
IT_FILTER =
IS_SEL_HIDE =
I_DEFAULT = 'X'
I_SAVE = 'X'
IS_VARIANT =
IT_EVENTS = IT_EVENTS[]
IT_EVENT_EXIT =
IS_PRINT =
IS_REPREP_ID =
I_SCREEN_START_COLUMN = 0
I_SCREEN_START_LINE = 0
I_SCREEN_END_COLUMN = 0
I_SCREEN_END_LINE = 0
I_HTML_HEIGHT_TOP = 0
I_HTML_HEIGHT_END = 0
IT_ALV_GRAPHICS =
IT_HYPERLINK =
IT_ADD_IT_FIELDCAT =
IT_EXCEPT_QINFO =
IR_SALV_FULLSCREEN_ADAPTER =
IMPORTING
E_EXIT_CAUSED_BY_CALLER =
ES_EXIT_CAUSED_BY_USER =
TABLES
T_OUTTAB = IT_PLAF_MAKT
EXCEPTIONS
PROGRAM_ERROR = 1
OTHERS = 2
IF SY-SUBRC <> 0.
MESSAGE ID SY-MSGID TYPE SY-MSGTY NUMBER SY-MSGNO
WITH SY-MSGV1 SY-MSGV2 SY-MSGV3 SY-MSGV4.
ENDIF.
REFRESH IT_FIELDCAT[].
ENDFORM. "ALV_DISPLAY
*& Form USER_COMMAND
text
-->UCOMM text
-->SELFIELD text
FORM USER_COMMAND
USING UCOMM LIKE SY-UCOMM
SELFIELD TYPE SLIS_SELFIELD.
Data: REF1 TYPE REF TO CL_GUI_ALV_GRID.
DATA WA LIKE LINE OF IT_PLAF_MAKT.
CALL FUNCTION 'GET_GLOBALS_FROM_SLVC_FULLSCR'
IMPORTING
E_GRID = REF1.
CALL METHOD REF1->CHECK_CHANGED_DATA.
CASE UCOMM.
WHEN '&BACK'.
LEAVE TO SCREEN 0.
WHEN '&EXIT'.
LEAVE TO SCREEN 0.
WHEN '&CANC'.
LEAVE TO SCREEN 0.
WHEN '&SAVE'.
CLEAR IT_ZCDR_D[].
LOOP AT IT_PLAF_MAKT INTO WA_PLAF_MAKT WHERE CHK = 'X'.
CLEAR WA_ZCDR_D.
WA_ZCDR_D-MANDT = SY-MANDT.
WA_ZCDR_D-CBNO = WA_PLAF_MAKT-CBNO.
WA_ZCDR_D-plnum = WA_PLAF_MAKT-PLNUM.
WA_ZCDR_D-MATNR = WA_PLAF_MAKT-MATNR.
WA_ZCDR_D-MAKTX = WA_PLAF_MAKT-MAKTX.
WA_ZCDR_D-KDAUF = WA_PLAF_MAKT-KDAUF.
WA_ZCDR_D-KDPOS = WA_PLAF_MAKT-KDPOS.
WA_ZCDR_D-AUFNR = WA_PLAF_MAKT-AUFNR.
APPEND WA_ZCDR_D to IT_ZCDR_D.
ENDLOOP.
LOOP AT IT_ZCDR_D INTO WA_ZCDR_D.
INSERT ZCDR_D FROM WA_ZCDR_D.
CLEAR WA_ZCDR_D.
ENDLOOP.
IF SY-SUBRC EQ 0.
MESSAGE S021(ZCBR) WITH PR_CBNO.
ENDIF.
IF IT_ZCDR_D IS INITIAL.
MESSAGE 'Select Atleast one Check Box' TYPE 'E' .
ENDIF.
WHEN 'IMPORT_INF'.
PERFORM IMPORT_REPORT.
WHEN 'EXPORT_INF'.
PERFORM EXPORT_REPORT.
WHEN 'UNIT_CONSU'.
PERFORM UNIT_CONSUMPTION.
ENDCASE.
ENDFORM. "USER_COMMAND
FORM set_events USING it_events TYPE slis_t_event.
DATA: x_event TYPE slis_alv_event.
clear x_event.
x_event-name = 'USER_COMMAND'.
x_event-form = 'USER_COMMAND'.
append x_event to it_events.
CLEAR x_event.
call function 'REUSE_ALV_EVENTS_GET'
EXPORTING
I_LIST_TYPE = 0
IMPORTING
ET_EVENTS = IT_EVENTS
EXCEPTIONS
LIST_TYPE_WRONG = 1
OTHERS = 2
if sy-subrc <> 0.
MESSAGE ID SY-MSGID TYPE SY-MSGTY NUMBER SY-MSGNO
WITH SY-MSGV1 SY-MSGV2 SY-MSGV3 SY-MSGV4.
endif.
read table it_events into x_event with key name = slis_ev_user_command.
if sy-subrc = 0.
x_event-form = 'USER_COMMAND'.
modify it_events from x_event index sy-tabix transporting form .
endif.
ENDFORM.
*& Form set_pf_status
text
-->RT_EXTAB text
FORM SET_PF_STATUS USING RT_EXTAB TYPE SLIS_T_EXTAB.
SET PF-STATUS 'Z_PFSTAT'.
ENDFORM. " set_pf_status
FORM IMPORT_REPORT.
TYPES: BEGIN OF TY_BOM,
MATMK LIKE STPOX-MATMK,
MTNRV LIKE ZCDR_D-MATNR,
IDNRK LIKE STPOX-IDNRK,
MNGLG LIKE STPOX-MNGLG,
MMEIN LIKE STPOX-MMEIN,
VPRSV LIKE STPOX-VPRSV,
UPRICE LIKE MBEW-STPRS,
TPRICE LIKE MBEW-STPRS,
END OF TY_BOM,
BEGIN OF TY_QUAN,
MATMK LIKE STPOX-MATMK,
MTNRV LIKE ZCDR_D-MATNR,
IDNRK LIKE STPOX-IDNRK,
MNGLG LIKE STPOX-MNGLG,
MMEIN LIKE STPOX-MMEIN,
UPRICE LIKE MBEW-STPRS,
TPRICE LIKE MBEW-STPRS,
END OF TY_QUAN,
BEGIN OF TY_T023T,
MATKL LIKE T023T-MATKL,
WGBEZ LIKE T023T-WGBEZ,
END OF TY_T023T,
BEGIN OF TY_T006A,
MMEIN LIKE T006A-MSEHI,
MSEHT LIKE T006A-MSEHT,
END OF TY_T006A,
BEGIN OF TY_IMP_FINAL,
SNO TYPE SY-INDEX,
HSCODE LIKE ZHSCODE-HSCODE,
WGBEZ TYPE T023T-WGBEZ,
SPEC(20) TYPE C,
MNGLG LIKE STPOX-MNGLG,
MSEHT LIKE T006A-MSEHT,
CNTRY(13) TYPE C,
UPRICE TYPE P LENGTH 16 DECIMALS 2,
TPRICE TYPE P LENGTH 16 DECIMALS 2,
CURRCODE TYPE C LENGTH 5,
END OF TY_IMP_FINAL,
BEGIN OF TY_MBEW,
MATNR LIKE MBEW-MATNR,
VPRSV LIKE MBEW-VPRSV,
STPRS LIKE MBEW-STPRS,
VERPR LIKE MBEW-VERPR,
END OF TY_MBEW.
DATA: WA_BOM TYPE TY_BOM,
WA_QUAN TYPE TY_QUAN,
WA_IMP_FINAL TYPE TY_IMP_FINAL,
WA_T023T TYPE TY_T023T,
WA_T006A TYPE TY_T006A,
WA_MBEW TYPE TY_MBEW.
DATA: IT_BOM TYPE TABLE OF TY_BOM,
IT_QUAN TYPE TABLE OF TY_QUAN,
IT_IMP_FINAL TYPE TABLE OF TY_IMP_FINAL,
IT_MBEW TYPE TABLE OF TY_MBEW.
DATA: IT_STPO TYPE STANDARD TABLE OF STPOX,
WA_STPO TYPE STPOX.
SELECT
MATNR
VPRSV
STPRS
VERPR
FROM MBEW
INTO CORRESPONDING FIELDS OF TABLE IT_MBEW.
WHERE MATNR EQ IT_MARA-MATNR. "MBEW
*I_STPO2 TYPE STANDARD TABLE OF STPOX.
LOOP AT IT_PLAF_MAKT INTO WA_PLAF_MAKT WHERE CHK = 'X'.
LOOP AT IT_ZCDR_D INTO WA_ZCDR_D .
CALL FUNCTION 'CS_BOM_EXPL_MAT_V2' -
How to make optimizer fetch and join values from Indexes, no table access.
Hi All,
i am having a query which is just checking the existence of the values according to some of the filter criteria, and involves two tables in join. and i want optimizer to find the existence i.e the reult of the query by only accessing indexes only, not to go through table scan using indexes. Is there any way so that i can modify my query or force the optimizer to do the same? below is the existing plan of the query in which its accessing tables using indexes, which causing bottleneck in my DB as these tables are bulky ones.
Execution Plan
Plan hash value: 1209914516
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | Pstart| Pstop |
| 0 | SELECT STATEMENT | | 1 | | 6 (17)| 00:00:01 | | |
| 1 | SORT AGGREGATE | | 1 | | | | | |
|* 2 | FILTER | | | | | | | |
| 3 | FAST DUAL | | 1 | | 2 (0)| 00:00:01 | | |
| 4 | NESTED LOOPS | | 1 | 24 | 4 (25)| 00:00:01 | | |
| 5 | SORT UNIQUE | | 1 | 10 | 2 (0)| 00:00:01 | | |
| 6 | TABLE ACCESS BY INDEX ROWID | INVOICELINEDISB | 1 | 10 | 2 (0)| 00:00:01 | | |
|* 7 | INDEX RANGE SCAN | IDX_INVLINEDISB_UOMCD | 1 | | 1 (0)| 00:00:01 | | |
| 8 | PARTITION HASH ITERATOR | | 1 | 14 | 1 (0)| 00:00:01 | KEY | KEY |
|* 9 | TABLE ACCESS BY GLOBAL INDEX ROWID| INVOICEHEADERDISB | 1 | 14 | 1 (0)| 00:00:01 | ROWID | ROWID |
|* 10 | INDEX UNIQUE SCAN | P_INVOICEHEADERDISB_PART | 1 | | 0 (0)| 00:00:01 | KEY | KEY |
Predicate Information (identified by operation id):
2 - filter( EXISTS (SELECT 0 FROM "XIGNCMN"."INVOICEHEADERDISB" "INVOICEHEADERDISB","XIGNCMN"."INVOICELINEDISB"
"INVOICELINEDISB" WHERE "INVOICELINEDISB"."UNITOFMEASURECD"='USD' AND
"INVOICEHEADERDISB"."INVOICEPK"="INVOICELINEDISB"."INVOICEPK" AND "INVOICEHEADERDISB"."PAYPK"=8135488395))
7 - access("INVOICELINEDISB"."UNITOFMEASURECD"='USD')
9 - filter("INVOICEHEADERDISB"."PAYPK"=8135488395)
10 - access("INVOICEHEADERDISB"."INVOICEPK"="INVOICELINEDISB"."INVOICEPK")
Statistics
0 recursive calls
0 db block gets
14 consistent gets
0 physical reads
0 redo size
410 bytes sent via SQL*Net to client
385 bytes received via SQL*Net from clientJonathan Lewis wrote:
930254 wrote:
Hi All,
i am having a query which is just checking the existence of the values according to some of the filter criteria, and involves two tables in join. and i want optimizer to find the existence i.e the reult of the query by only accessing indexes only, not to go through table scan using indexes. Is there any way so that i can modify my query or force the optimizer to do the same? below is the existing plan of the query in which its accessing tables using indexes, which causing bottleneck in my DB as these tables are bulky ones.
Execution Plan
Plan hash value: 1209914516
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | Pstart| Pstop |
| 0 | SELECT STATEMENT | | 1 | | 6 (17)| 00:00:01 | | |
| 1 | SORT AGGREGATE | | 1 | | | | | |
|* 2 | FILTER | | | | | | | |
| 3 | FAST DUAL | | 1 | | 2 (0)| 00:00:01 | | |
| 4 | NESTED LOOPS | | 1 | 24 | 4 (25)| 00:00:01 | | |
| 5 | SORT UNIQUE | | 1 | 10 | 2 (0)| 00:00:01 | | |
| 6 | TABLE ACCESS BY INDEX ROWID | INVOICELINEDISB | 1 | 10 | 2 (0)| 00:00:01 | | |
|* 7 | INDEX RANGE SCAN | IDX_INVLINEDISB_UOMCD | 1 | | 1 (0)| 00:00:01 | | |
| 8 | PARTITION HASH ITERATOR | | 1 | 14 | 1 (0)| 00:00:01 | KEY | KEY |
|* 9 | TABLE ACCESS BY GLOBAL INDEX ROWID| INVOICEHEADERDISB | 1 | 14 | 1 (0)| 00:00:01 | ROWID | ROWID |
|* 10 | INDEX UNIQUE SCAN | P_INVOICEHEADERDISB_PART | 1 | | 0 (0)| 00:00:01 | KEY | KEY |
Predicate Information (identified by operation id):
2 - filter( EXISTS (SELECT 0 FROM "XIGNCMN"."INVOICEHEADERDISB" "INVOICEHEADERDISB","XIGNCMN"."INVOICELINEDISB"
"INVOICELINEDISB" WHERE "INVOICELINEDISB"."UNITOFMEASURECD"='USD' AND
"INVOICEHEADERDISB"."INVOICEPK"="INVOICELINEDISB"."INVOICEPK" AND "INVOICEHEADERDISB"."PAYPK"=8135488395))
7 - access("INVOICELINEDISB"."UNITOFMEASURECD"='USD')
9 - filter("INVOICEHEADERDISB"."PAYPK"=8135488395)
10 - access("INVOICEHEADERDISB"."INVOICEPK"="INVOICELINEDISB"."INVOICEPK")
The sort unique at line 5 is surprising, I can't think of an obvious reason why it should appear unless the optimizer is trying to do something very clever to work around a problem we can't see (such as a statistics error with the hash partitioned indexe).
Assuming that the test would do better starting with invoiceheaderdisn.paypkl I have to ask if you have an index on INVOICELINEDISB(INVOICEPK).The optimizer's choice of driving table indeed looks odd. Could it be due to misleading statistics or plain bug or just a case of CBO preferring a non-partitioned table over partitioned table when deciding the driving table? I must admit this design does look odd as it appears INVOICEHEADERDISB is a parent table and INVOICELINEDISB is a child table but somehow the parent table has been partitioned (using hash partitioning, I assume) but the child table is not.
However, once CBO has decided the driving table, the SORT UNIQUE is not quite surprising. Assuming optimizer knows that there is a parent-child relationship between INVOICEHEADERDISB and INVOICELINEDISB table (based on INVOICEPK column), CBO needs to access only INVOICEPK and UNITOFMEASURECD columns fron the INVOICELINEDISB table in order to process the join. It uses index range scan on UNITOFMEASURECD table in order to get (part of) the necessary data and then accesses INVOICELINEDISB table to get the values of INVOICEPK column. Being a child table, it is possible that the driving row source will contain duplicate values for INVOICEPK column but not necessarily sorted. As CBO knows that outer table (i.e. INVOICEHEADERDISB) has a PK on INVOICEPK column, each row in driving row source will have either 1 or 0 rows matching from outer table. It appears that CBO "decides" that by eliminating the duplicate values of the INVOICEPK from driving row source, it can reduce the number of times the INVOICEHEADERDISB table is accessed.
Now I am not sure if CBO does all this (eliminating duplicates from driving row source) only because the outer table is partitioned.
Coming back to OP's original question, I believe OP will have to change the index definitions in order to avoid table access for this query. But there has to be a strong and logical argument to make this kind of change for just one query.
Hope this helps. -
Why Index-organized Table (IOT) is so slow during bulk/initial insert?
Tested in 11.1.0.7.0 RAC on RHEL 5 with ASM and 16KB block size.
Table is not wide: PK contains 4 columns and the leading 2 are compressed because they have relatively low cardinality; 2 other columns are included; the table contains another 4 audit columns; overflow table space defined.
Created 2 tables, one is IOT, the other is a normal heap-organized table with "COMPRESS FOR ALL OPERATIONS". Both tables have been range partitioned by the first column into 8 partitions, and DOP is set to 8.
Initial load volume is about 160M rows. Direct Path insert is used with parallel degree 8.
After initial load, create PK for the 4 columns with the leading 2 compressed on the normal table. The IOT occupied about 7GB storage; the normal table occupied 9GB storage (avg_row_len = 80 bytes) and the PK occupied 5.8GB storage.
The storage saving of IOT is significant, but it took about 60 minutes to load the IOT, while it only took 10 minutes to load the heap-organized table and then 6 minutes to create the PK. Overall, the bulk insert for IOT is about 4 times slower than the equivalent heap-organized table.
I have ordered the 4 columns in PK for the best compression ratio (lower cardinality comes first) and only compress the most repetitive leading columns (this matches ORACLE's recommendation in index_stats after validate structure), partition is used to reduce contention, parallel degree is amble, /*+ append */ is used for insert, the ASM system is backed with high-end SAN with a lot of I/O bandwidth.
So it seems that such table is good candidate for IOT and I've tried a few tricks to get the best out of IOT, but the insert performance is quite disappointing. Please advise me if I missed anything, or you have some tips to share.
Thanks a lot.
CREATE TABLE IOT_IS_SLOW
GROUP_ID NUMBER(2) NOT NULL,
BATCH_ID NUMBER(4) NOT NULL,
KEY1 NUMBER(10) NOT NULL,
KEY2 NUMBER(10) NOT NULL,
STATUS_ID NUMBER(2) NOT NULL,
VERSION NUMBER(10),
SRC_LAST_UPDATED DATE,
SRC_CREATION_DATE DATE,
DW_LAST_UPDATED DATE,
DW_CREATION_DATE DATE,
CONSTRAINT PK_IOT_IS_SLOW
PRIMARY KEY (GROUP_ID, BATCH_ID, KEY1, KEY2)
ORGANIZATION INDEX COMPRESS 2
INCLUDING VERSION
NOLOGGING
PCTFREE 20
OVERFLOW
PARALLEL ( DEGREE 8 )
PARTITION BY RANGE(GROUP_ID)
PARTITION P01 VALUES LESS THAN (2),
PARTITION P02 VALUES LESS THAN (3),
PARTITION P03 VALUES LESS THAN (4),
PARTITION P04 VALUES LESS THAN (5),
PARTITION P05 VALUES LESS THAN (6),
PARTITION P06 VALUES LESS THAN (7),
PARTITION P07 VALUES LESS THAN (8),
PARTITION P08 VALUES LESS THAN (MAXVALUE)
);Even if /*+ APPEND */ is ignored for IOT, it is too slow, isn't it?David_Aldridge wrote:
oftengo wrote:
>
Direct-path INSERT into a single partition of an index-organized table (IOT), or into a partitioned IOT with only one partition, will be done serially, even if the IOT was created in parallel mode or you specify the APPEND or APPEND_VALUES hint. However, direct-path INSERT operations into a partitioned IOT will honor parallel mode as long as the partition-extended name is not used and the IOT has more than one partition.
>
http://download.oracle.com/docs/cd/E11882_01/server.112/e17118/statements_9014.htm
Hmmm, that's very interesting. I'm still a bit cynical though -- in order for direct path to work on an index organized table by appending blocks I would think that some extra conditions would have to be satisfied:
* the table would have to be empty, or the lowest-sorting row of the new data would have to be higher than the highest-sorting row of the existing data
* the data would have to be sorted
... that sort of thing. Maybe I'm suffering a failure of imagination though.Could be. From a Tanel Poder post:
>
The “direct path loader” (KCBL) module is used for performing direct path IO in Oracle, such as direct path segment scans and reading/writing spilled over workareas in temporary tablespace. Direct path IO is used whenever you see “direct path read/write*” wait events reported in your session. This means that IOs aren’t done from/to buffer cache, but from/to PGA directly, bypassing the buffer cache.
This KCBL module tries to dynamically scale up the number of asynch IO descriptors (AIO descriptors are the OS kernel structures, which keep track of asynch IO requests) to match the number of direct path IO slots a process uses. In other words, if the PGA workarea and/or spilled-over hash area in temp tablespace gets larger, Oracle also scales up the number of direct IO slots. Direct IO slots are PGA memory structures helping to do direct IO between files and PGA.
>
So I'm reading into this that somehow these temp segments handle it, perhaps because with parallelism you have to be able to deal anyway. I speculate the data is inserted past the high water mark, then any ordering issues left can be resolved before moving the high water mark(s). Maybe examining where segments wind up in the data files can show how this works.
>
I can't find anything in the documentation that speaks to this, so I wonder whether the docs are really talking about a form of conventional path parallel insert into an IOT and not true direct path inserts.
One way to check, I think, would be to get the wait events for the insert and see whether the writes are direct. -
Please help for create index for table in db2
Dear Consultants,
Our Production Servers have a problem, when user input materials in t-code VA01, the check data take long time to complete.
I was create a incident on SAP Portal and they recommended to create a new index on table:
VBRP in the order MANDT, AUBEL and AUPOS.
but we don't sure how to do this, please help us !
The SAP consultant message:
" It was identified that there is one SQL statement which was
responsible for the majority of the time spent during the VA01
transaction. It accounted for around 49 seconds.
The SQL statement was analysed and a selectivity analysis was carried
out on certain fields specified in the WHERE clause. The statement is
currently executed via a full table scan which is not an efficient
access. It is therefore recommended to create a new index on table
VBRP in the order MANDT, AUBEL and AUPOS. "
Our System Landscape IS : DEV -> QAS -> Production and DataBase server : db2 9.07 , SAP ECC 6.0, windows server 2008
Thanks and Best Regards,
Hien NguyenHi Deepak,
Could you please tell me the places where can i post the message for ABAPer, i don't know to choose : ABAP Development , ABAP Testing and Troubleshoo… or somthing else
Sorry for my amateur !
Thanks you very much.
Best Regards,
Hien
Maybe you are looking for
-
Tabbedpanels works in FF and Safari but not IE6 & IE7
I've got a page with tabbed panels pulled from an XML file. It works fine in Safari and Firefox but silently fails in IE 6 and 7 The page is here: http://www.hillcrest.jobs/rhino.php The XML feed is here: http://www.hillcrest.jobs/rhinofeed.php I'm f
-
How do I open a .xps file on a mac? Thanks for help. Wahine in Kauai
-
Problem in service testing in SICF.
Hi all Our users are not able to test any of the services in SICF. Whenever they try to test any service, they either get the error message "400 Session timed out - please log in again", or they get an empty IE window with message sap-client=800. fol
-
How to remove duplicate iTunesU entries?
I have so many multiple entries for iTunesU that it isn't practical to delete them - they number in the 100s. Yes, I've found the folder and confirmed that these are exact duplicates. Is there any way to identify and remove these?
-
Navigation block with tab page canvas
Hi, With content canvas, we can navigate to the next block with CRTL/PgDown, With tab canvas if i press CRTL/PgDown, i go directly to the next tab page!! Any solution to avoid this? Thanks. null