Table or Index creation / alteration form

Table HRP1001 (id) Index on Infotype 1001 (Short text) Index Y02(System ID : G1B) (id) This form is to be used when altering indexes or size critical table / indexes. It is to be attached to the development Fields OTYPE
OBJID BEGDA ENDDA SCLAS specification and the CI that will support the promotion of the object to production

Unique index ?
CI "Major Risk"
(See Summary of changes)

Blue items requires validation by Basis when the change is initiated. For that purpose, the requester must post a myRequest with the current document attached.

Size estimates : Table / Index Y02 DEVELOPMENT ID: RM17515698

for new large tables or indexes, to be provided by CD for existing tables/indexes : prod size to be provided by Basis AOA AMS EUR Center X

Class: /GLB/CL_7GTIR_DPR_ROL_GENERAL Method: GET_EMAIL_IDS Description: Data will be selected from table HRP1001 on the basis of fields OTYPE OBJID BEGDA ENDDA SCLAS among of which the last field is not part of the primary key and also the minimum requirement of the primary key fields are not available during the selection.therefore index needs to be created.

Summary of change (help to decide if CI to be classified as Major Risk) Description of the change : Comment Special care for large table or index creation Special care for large table alteration (potentially large table with field definition changed, table conversion required) Relocation required (potentially large new table / indexes). Table space must exists (TS creation may be part of the change)

Tables creation / alteration

It is assumed here that the table creation has been approved by the Data Administrator and the Dictionary Administrator.

Table or Index creation / alteration form

Table creation From a basis perspective, the table has to be properly classified so it is affected to the proper physical structure (technical settings -> data class and size category). When creating potentially large tables, the basis team must be contacted to check whether the storage parameters are apropriate (table/index relocation may be required : table / index stored in a dedicated tablespace). When doing initial data loading, Data Integration Team will have to notify basis that data loading is taking place. Table alteration: The impact when altering tables (directly or indirectly via field domains) can be huge on large table. When a field attribute is changed (field length) or when a field is moved from a position, the activation of the table will generate table adjustments that requires temporary staging tables (QCM tables). These QCM tables require as much space as the original table and their creation may require preventive actions (tablespace checks .). Additionally : table locking during table creation process requires all the application processes that rely on this table to be stopped. when altering table, a long conversion process will impact the outage duration. Also, special considerations should be aplied when adding new fields in existing table when default "NOT NULL" is assigned. Assigning initial values can be very time-consuming for large tables.

Table or Index creation / alteration form

Indexes creation / alteration
Index Creation : Regardless performances considerations, there is no concern when creating new indexes exept for large indexes which of course need required disk space to be made available in the tablespace. Also, a relocation of the associated table is associated to a relocation of the index.

Golden rules for index creation

Golden Rules for creating/altering indexes (see also SAP training and SAP documentation) create as few indexes as possible but as many as necessary create disjunct indexes only create indexes with as few fields as possible use selective fields only if possible use selective fields at the beginning if possible use unselective fields in case that only a small number of rows out of the complete table is having the value you look for do not create indexes that can be used unintentionally do not alter SAP indexes except recommended in a Note or in a SAP message Explanation

index maintenance generates overloads in table maintenance overlapping indexes creates complexity for the optimizer and may conduct to impredictable access strategy for the optimizer sizing and performance considerations in the where clause of selects, use fields in the index usage of first positions fields of the indexes must be promoted in where clause, use fields not pertaining to indexes only if other field of the where clause are very restrictive Indexes creation should clearly respond to understandable access strategy or even better, business processes. The standard indexes are optimized for SAP standard coding and should not be changed unless notified by SAP

Checklist for index creation Done Result Check ...

Design Implementation
for similar statements in order to make indexes reusable if the program already knows values of fields that could be added to the where clause in order to use an existing index if it is possible to access another table first getting fields for the where clause in order to use an existing index (see also SAP Notes 185530, 187906, 191492) sap notes generally for tables you touch other selects inside abap: are there fields available to make the select more selective ? statistcs update: run stats on the table after every index change before looking at the statements (DB6STATS transaction) if the table is ACTIV=N in DBSTATC for the table, contact Basis to run db2_table_stat_voltables.sh (never run db2 reorgchk or runstats by hand) SQL caches on different days in different systems before a decision is made. SQL traces produced with and without the new index in order (to measure the benefit) Make sure enough size is available. In case of doudt, post a ticket to basis to validate : give an estimate of the index size (number of records * index length) When creating the CI to move the index to pre-prod and prod, for large table, classify the CI as "risk : Major" and clearly document the potential sizing issue so the index is created in apropriate conditions (outage window ....) In the CI, request the implementer to check (on a significant period) the correct behavior of all indexes of the table (SQL cache) in order to find out if all accesses are still optimal. In case of issues, a SC ticket should be raised.