ch05.htm

这个是sap开发语言abap的教育文档

<TT>Trace SQL is switched off</TT>.
<LI>Press the List Trace pushbutton. The Trace SQL Database Requests
dialog box is displayed. The fields on this screen will already
contain values.
<LI>Press the OK button. You might need to wait a little while,
at most a couple of minutes. The Trace SQL: List Database Requests
screen is displayed.
<LI>Type <B>%sc</B> in the Command field and press the Enter key.
The Find dialog box is displayed.
<LI>Type the name of the table you are tracing in the Search For
field. (This is the table named in the <TT>select</TT> statement
in your ABAP/4 program.)
<LI>Press the Find button. A search results list should be displayed
with your table name highlighted.
<LI>Click on the first highlighted table name. You are returned
to the Trace SQL: List Database Requests screen. Your cursor is
positioned on the first line containing your table name. To the
right of it, in the Operation column, should be the word <TT>PREPARE</TT>,
<TT>OPEN</TT>, or <TT>REOPEN</TT>.
<LI>Press the Explain SQL button on the Application toolbar. The
Show Execution Plan for SQL Statement screen is displayed.
<LI>Scroll down to the execution plan. The index used will be
displayed in blue.
</OL>
<P>
You have learned how to execute a SQL trace. This will help you
determine what index is being used.
<H2><A NAME="DisplayingTechnicalSettings"><FONT SIZE=5 COLOR=#FF0000>
Displaying Technical Settings</FONT></A></H2>
<P>
To display the technical settings for a table, display the table
and press the Technical Settings button on the Application toolbar.
(If the button is not there, your window might be too narrow.
Try widening your window or use the menu path Goto-&gt;Technical
Settings.) To modify these settings, press the Display &lt;-&gt;
Change button on the Application toolbar. The ABAP/4 Dictionary:
Maintain Technical Settings screen is displayed, as shown in Figure
5.4.
<P>
<A HREF="javascript:popUp('f5-4.gif')"><B>Figure 5.4 :</B> <I>On the ABAP/4 Dictionary: Maintain Technical
Settings screen, you can set the data class, size category, and
buffering options</I>.</A>
<H3><A NAME="DataClass">
Data Class</A></H3>
<P>
<IMG SRC="../button/newterm.gif" tppabs="http://pbs.mcp.com/ebooks/0672312174/button/newterm.gif">
<P>
The <I>data class</I> determines the tablespace that the table
is assigned to. (The term &quot;tablespace&quot; applies to Oracle
databases. For Informix, substitute the term &quot;DB space.&quot;)
A <I>tablespace</I> is a physical file on disk that is used to
hold tables. Every table is assigned to one tablespace. Tables
with similar characteristics are usually grouped into one tablespace,
so tablespaces are the administrative units used by the DBA to
manage the database. For example, tables that grow quickly will
be grouped together in a tablespace on a disk with a lot of free
space.
<P>
Each data class has an associated tablespace. When you activate
a table, it is created in the tablespace associated with that
data class. If you change the data class when the table is active,
nothing happens; it doesn't move to another tablespace.
<P>
The important data classes are:
<UL>
<LI><TT><I>APPL0</I></TT><I> or
master data</I>. By choosing APPL0 (master data), you signify
that the table is not updated often and grows slowly. It will
be placed in a tablespace with similar tables. Vendor master and
customer master tables are good examples of master data.
<LI><TT><I>APPL1</I></TT><I> or
transaction data</I>. By choosing APPL1 (transaction data), you
signify that the table is expected to be updated often and to
grow quickly. Orders placed with vendors and orders received from
customers are good examples of transaction data. Tables containing
these orders will have a data class of APPL1.
<LI><TT><I>APPL2</I></TT><I> or
customizing data</I>. By choosing APPL2 (customizing data), you
signify that the table's contents are determined before implementation
and do not change often after that. Check tables and their associated
text tables, such as <TT>ztxt005</TT> and <TT>ztxt005t</TT>, are
good examples of tables that should have a data class of APPL2.
</UL>
<P>
In addition to these categories, there might be <TT>USER</TT>
data classes as well. These are created by your DBA, who will
direct you in choosing them at the appropriate times.<P>
<CENTER>
<TABLE BORDERCOLOR=#000000 BORDER=1>
<TR VALIGN=TOP><TD WIDTH=600><B>NOTE</B></TD></TR>
<TR VALIGN=TOP><TD WIDTH=600>
<BLOCKQUOTE>
Other data classes can be displayed by pressing the down arrow at the end of the Data Class field and then pressing the System Data Types button. These classes should only be used by SAP; they are for R/3 system tables that hold, for example, Data Dictionary information and program source code.</BLOCKQUOTE>

</TD></TR>
</TABLE>
</CENTER>
<P>
<H3><A NAME="SizeCategory">
Size Category</A></H3>
<P>
The Size Category field enables you to specify the maximum number
of records you expect this table to hold. You are setting the
size of the initial extent and next extents, as well as the maximum
number of extents allowed for this table. An <I>extent</I> is
the amount of space allocated for a table. The initial extent
is the amount of space allocated for a table when it is created.
If a table uses up that space, another extent will be allocated,
causing the table's space to be extended.
<P>
The size categories are always 0 through 4, but the number of
expected records in each size category will change with every
table based on the length of a row. Choose an appropriate category
based on the maximum number of records you expect that table to
hold.<P>
<CENTER>
<TABLE BORDERCOLOR=#000000 BORDER=1>
<TR VALIGN=TOP><TD WIDTH=600><B>CAUTION</B></TD></TR>
<TR VALIGN=TOP><TD WIDTH=600>
<BLOCKQUOTE>
When choosing a size category, be generous. In R/3 it is much better to over-estimate than underestimate this parameter. If the size category is too small and the table grows larger than the initial allocation, the RDBMS allocates another extent. Secondary extents reduce performance and require a table-space reorganization to remove. Reorganizations can be very difficult to perform on a large database, especially one that requires high availability. It is much easier to reduce an overly generous size category than it is to increase an underestimated one.</BLOCKQUOTE>

</TD></TR>
</TABLE>
</CENTER>
<P>
<H3><A NAME="DisplayingtheNumberofExtentsAllocatedtoaTable">
Displaying the Number of Extents Allocated to a Table</A></H3>
<P>
You can display the number of extents allocated for a table by
using the following procedure.
<P>
<IMG SRC="../button/screencam.gif" tppabs="http://pbs.mcp.com/ebooks/0672312174/button/screencam.gif">
<P>
Start the ScreenCam &quot;How to Display the Number of Extents
Used by a Table&quot; now.
<P>
To display the number of extents for a table:
<OL>
<LI>Run transaction DB02. (Type <B>/ndb02</B> in the Command field
and press the Enter key.) The Database Performance: Tables and
Indexes screen is displayed.
<LI>Press the Detailed analysis pushbutton. A Memory Management:
Tables and Indexes dialog box is displayed.
<LI>Type the name of the table in the Tables field and press the
OK button. A Memory Management: Tables and Indexes screen is displayed.
The table name appears in the list.
<LI>Double-click on the table name. A Memory Management: Tables
and Indexes dialog box is displayed.
<LI>Choose the Extents radio button.
<LI>Press the OK button. A Memory Management: Tables and Indexes
screen is displayed, containing the list of extents, their tablespace
names, extent numbers, physical file number, block size, extent
size, and number of blocks in the extent. There is one line in
this list for each extent.
</OL>
<P>
You have learned how to look at the number of extents allocated
in a table. This will give information about whether the table
will need to be reorganized or not.
<H3><A NAME="BufferingaTable">
Buffering a Table</A></H3>
<P>
As mentioned on Day 1, data can be buffered in RAM on the application
server. This is controlled on a per-table basis, and is specified
in the technical settings for each table (refer to Figure 5.4).
<P>
Whenever an Open SQL statement is used to read a record, the data
buffer is checked first to see whether it is there. If not, the
data is read from the database. If the table's attributes indicate
that the data should be buffered, the record is saved in RAM on
the application server in data buffers. Later, if that record
is read again, it is read from the buffer instead of the database.
This process is diagrammed in Figure 5.5.
<P>
<A HREF="javascript:popUp('f5-5.gif')"><B>Figure 5.5 :</B> <I>Data can be buffered in RAM on the application
sever</I>.</A>
<P>
By buffering data, you increase performance in two important ways:
<UL>
<LI>The programs using the buffered data run faster because they
don't have to wait for it to come from the database. This reduces
delays waiting for the database and the network that connects
it.
<LI>The other programs that need to access the database run faster
because there is less load on the database and less traffic on
the network.
</UL>
<P>
Buffering a table can cause a <TT>select</TT> to run 10 to 100
times faster or more. At first thought, it might seem like a good
idea to buffer every table in the system. However, buffers are
stored entirely in RAM, so space is limited by the amount of RAM
available. In fact, there is so much more data than there is RAM
that tables must be buffered judiciously to prevent overruns.
If a buffer overruns, it might swap to disk, which can obliterate
any performance gained by buffering.
<P>
Tables containing a numeric data type in the primary key cannot
be buffered. The DDIC numeric data types are <TT>CURR</TT>, <TT>DEC</TT>,
<TT>FLTP</TT>, <TT>INT1</TT>, <TT>INT2</TT>, <TT>INT4</TT>, <TT>PREC</TT>,
and <TT>QUAN</TT>.<P>
<CENTER>
<TABLE BORDERCOLOR=#000000 BORDER=1>
<TR VALIGN=TOP><TD WIDTH=600><B>TIP</B></TD></TR>
<TR VALIGN=TOP><TD WIDTH=600>
<BLOCKQUOTE>
Transaction ST02 displays buffers and usage statistics. On the Tune Summary screen, the data buffers are named Generic Key and Single Record. A double-click on each of these lines will display a detailed analysis. From there, the objects in the buffer can be displayed by pressing the Buffered Objects button on the Application toolbar.</BLOCKQUOTE>

</TD></TR>
</TABLE>
</CENTER>
<P>
<P>
The Basis consultant is responsible for monitoring the buffers
and preventing buffer shortages from slowing the system down.
Before buffering a table, it is a good idea to talk to your Basis
consultant.
<H4>Buffer Synchronization</H4>
<P>
<IMG SRC="../button/newterm.gif" tppabs="http://pbs.mcp.com/ebooks/0672312174/button/newterm.gif">
<P>
If you have two application servers, the same record can be buffered
on each server. This would not be a problem if it were not for
the fact that data can be updated. If a buffered record is updated,
the changes must be communicated to the other application server.
This is done in a process known as <I>buffer synchronization,</I>
which occurs at 1- to 4-minute intervals depending on your system
configuration.
<P>
For example, as shown in Figure 5.6, suppose user 1 is logged
on to application server 1 and user 2 is logged on to application
server 2. User 1 reads record 1. Record 1 is buffered on application
server 1.
<P>
<A HREF="javascript:popUp('f5-6.gif')"><B>Figure 5.6 :</B> <I>Step A: User 1 reads record 1, causing it
to be buffered on application server 1</I>.</A>
<P>
In Figure 5.7, user 2 reads record 1. The same record is now in
the buffers of both application servers.
<P>
<A HREF="javascript:popUp('f5-7.gif')"><B>Figure 5.7 :</B> <I>Step B: User 2 also reads record 1, causing
it to be buffered on application server 2</I>.</A>
<P>
In Figure 5.8, user 1 updates record 1. The update is reflected
in both the database and the buffers on server 1, but the old
record is still on server 2. An entry is made in the <I>synchronization
log</I> on the database server indicating that record 1 has been
updated.
<P>
<A HREF="javascript:popUp('f5-8.gif')"><B>Figure 5.8 :</B> <I>Step C: User 1 updates record 1, causing
it to be updated in the data-base and in the buffer on application
server 1</I>.</A>
<P>
In Figure 5.9, user 2 reads record 1. The old version of record
1 is found in the buffer, so user 2 sees old data. User 2 will
not see the new version of record 1 until a buffer synchronization
occurs.
<P>
<A HREF="javascript:popUp('f5-9.gif')"><B>Figure 5.9 :</B> <I>Step D: User 2 reads record 1 and gets stale
data</I>.</A>
<P>
In Figure 5.10, the buffer synchronization process detects that
the synchronization interval has expired and begins synchronization.
It reads the synchronization log on the database server and determines
that record 1 is out of sync. It then marks that record as invalid
in the buffer. It does <I>not</I> yet refresh the record in the
buffer from the database.
<P>
<A HREF="javascript:popUp('f5-10.gif')"><B>Figure 5.10:</B> <I>Step E: The buffer synchronization process
invalidates record 1 in the buffer on application server 2</I>.</A>
<P>
In Figure 5.11, user 2 reads record 1 again. This time, record
1 has been marked invalid in the buffer, so it is fetched from
the database, thereby refreshing the buffer on application server