|
ABAP Tutorials -
ABAP Data Dictionary
|
|
Written by Varun
|
|
Wednesday, 26 November 2008 17:04 |
Database Utility
The Database (DB) Utility is a tool used in SAP to serve as a interface between the database management software (i.e., ORACLE, INFORMIX, DB2, INGRES, etc.) and the ABAP Dictionary. It is used to:
- Convert data (i.e., change field lengths and data types, etc.)
- Activate objects in the ABAP Dictionary
- Create tables and indexes
- Perform all standard table operations in the database that were entered in the ABAP Dictionary
The DB Utility automatically writes the SQL commands necessary to create, change and delete tables and indexes in the physical database, and records the tables in the ABAP Dictionary. As the DB Utility is operating, a log file gets created which contains information on whether or not the conversion was successful and the point of failure during the conversion if it was not successful. The DB Utility can be run either online or in the background. You can also manually run the DB Utility from any ABAP Dictionary screen under the UTILITIES menu or transaction SE14. Indexes To improve performance, SAP automatically creates a primary index (id 0) for transparent tables based on the primary key. You can also define your own secondary indexes for transparent tables. Indexes accelerate the reading of tables when the system looks for records satisfying specific search criteria. The system determines the most efficient index by which to select data for the specific request. An index serves as a sorted copy of the table reduced to specific fields, with a pointer to the remaining fields. Database indexes are defined ABAP Dictionary and stored in the physical database. From the ABAP table maintenance screen use the menu path GoTo->Indexes. A pop-up window appears. Assign a 3-character id to your index. Provide a short text and select the field(s) by which the table needs to be indexed. Sometimes the presence of an index causes a performance problem. You can indicate the optionality of the index with different databases. Creating an index on an SAP table requires a repair, but it will not get overwritten with an upgrade.
In the cases where database accesses are necessary and appropriate, it is imperative to perform those accesses as efficiently as possible. The single most important method of optimizing a database access is by using an index. An index is a set of fields from a table that is sorted and then stored in a location separate from the table itself. Each record in the index contains a pointer to matching record(s) in the actual database table. In contrast, if each index record matches exactly one record in the table, and if all the fields of the index are specified in the query, a unique index scan can be performed. Queries based on a table’s full primary key always fulfil this criterion - such as by client (implicit if using Open SQL) and customer number in table KNA1. In this case, once the DBMS finds the matching record in the index, its work is almost done. All it must do is follow the pointer from the index to the solitary table record that it knows will satisfy the query.
In general, indexed reads are much quicker than normal table reads, and some types of indexed reads are quicker than others. A unique index scan is generally faster than an index range scan, because it has less data to sort through and retrieve. The smaller the amount of data being processed by a query, the faster it will run. Here are some guidelines: - Always make your queries as selective as possible.
- Use indexed reads over full table scans.
- Use unique index scans when possible.
|