ch05.htm

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

2.
<P>
<A HREF="javascript:popUp('f5-11.gif')"><B>Figure 5.11:</B> <I>Step F: User 2 tries to re-read record
1 but it is marked invalid in the buffer. It is refreshed from
the database</I>.</A>
<P>
As shown in Figures 5.6 through 5.11, buffer synchronization uses
a synchronization process on each application server and a synchronization
log on the database server. At a predefined interval, each synchronization
process checks the log to see whether any buffered data has been
modified. Data that has been modified is marked invalid in the
buffer. The next time that data is read, it is refreshed from
the database.
<P>
The Basis consultant sets the length of the buffer synchronization
interval using the <TT>rdisp/bufreftime</TT> parameter.
<P>
To display it, use transaction RZ10 as follows:
<UL>
<LI>Start transaction RZ10 (type <B>/nrz10</B> in the Command
field and press the Enter key). The Edit Profiles screen is displayed.
<LI>Choose the menu path Goto-&gt;Profile Values-&gt;Of a Server.
The Active Application Servers screen is displayed.
<LI>Double-click on an application server. You will see a list
of all the profile parameter values for that server.
<LI>Type <B>%sc</B> in the Command field and press the Enter key.
The Find dialog box is displayed.
<LI>Type <B>rdisp/buf</B> in the Search For field and press the
Enter key. The buffer parameters are displayed and highlighted.
<LI>Click on the highlighted word <TT>rdisp/bufreftime</TT>.
<LI>The refresh time (in seconds) is displayed on the right side
of the list.
</UL>
<H4>Updating Buffered Tables</H4>
<P>
If you code a transaction that updates a buffered table, you must
always be sure to go to the database and get the most up-to-date
information before allowing a user to change it. The following
example illustrates this point. Record locking is mentioned in
the following paragraph for the sake of completeness.
<P>
Suppose record 1 contains fields <TT>F1</TT> and <TT>F2</TT>.
This time, user 2 reads it first, causing it to be buffered on
server 2 (see Figure 5.12).
<P>
<A HREF="javascript:popUp('f5-12.gif')"><B>Figure 5.12:</B> <I>Step A: User 2 reads record 1, causing
it to be buffered on application server 2</I>.</A>
<P>
User 1, now wanting to update record 1, locks it and reads it
(see Figure 5.13).
<P>
<A HREF="javascript:popUp('f5-13.gif')"><B>Figure 5.13:</B> <I>Step B: User 1 locks and reads record one,
causing it to be buffered on application server 1</I>.</A>
<P>
User 1 changes <TT>F1</TT>, writes it to the database (see Figure
5.14), and unlocks it.
<P>
<A HREF="javascript:popUp('f5-14.gif')"><B>Figure 5.14:</B> <I>Step C: User 1 updates record 1, causing
it to be updated in the database and in the buffer on application
server 1. The lock is removed</I>.</A>
<P>
At this point, the buffer on application server 2 still has the
original copy of record 1 with the original contents of <TT>F1</TT>.
If user 2 locks record 1 and reads it (from the buffer), changes
<TT>F2</TT> (see Figure 5.15), and then saves it to the database,
the changes made by user 1 will be lost (see Figure 5.16).
<P>
<A HREF="javascript:popUp('f5-15.gif')"><B>Figure 5.15:</B> <I>Step D: User 2 reads the old record 1 and
locks it</I>.</A>
<P>
<A HREF="javascript:popUp('f5-16.gif')"><B>Figure 5.16:</B> <I>Step E: User 2 saves record 1 to the database,
overwriting user 1's change</I>.</A><BR>
<P>
<IMG SRC="../button/newterm.gif" tppabs="http://pbs.mcp.com/ebooks/0672312174/button/newterm.gif">
<P>
Use <TT>bypassing buffer</TT> on the <TT>select</TT> statement
when you need the most up-to-date information, for example, <TT>select
* from ztxtlfa1 bypassing buffer</TT>. Doing so causes the buffer
to be ignored and the data to be read directly from the database.
You should use this whenever you are <I>reading for update</I>,
that is, reading a record that will be updated and written back
to the database.
<P>
For example, in step D, if user 2 used <TT>bypassing buffer</TT>
to read the record, the most up-to-date version of the record
would have been read and user 1's changes would not have been
lost.<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>
Bypassing the buffer for updates provides the best balance between safety and speed. However, if you can be sure that all updates are done from a single application server, you don't need to code <TT>bypassing buffer</TT>. Bypassing the buffer does slow the update process a little because a database access is required. If you need the maximum amount of speed for updates, and if you can be sure that only one application server will be used, this alternative might work for you. Talk to your Basis consultant to find out whether it can be arranged.
</BLOCKQUOTE>

</TD></TR>
</TABLE>
</CENTER>
<P>
<H4>Summarizing the Approaches for Buffering with Updates</H4>
<P>
You can take one of three buffering approaches for tables that
can be updated. In order of best to worst performance, they are
as follows:
<UL>
<LI>Buffer the table, do not use <TT>bypassing buffer</TT>, and
ensure that all updates are done from a single application server.
<LI>Buffer the table and use <TT>bypassing buffer</TT>.
<LI>Do not buffer the table.
</UL>
<P>
If a table is updated often, do not use the <TT>bypassing buffer</TT>
approach. Each update will cause the buffers on all other application
servers to be reloaded at the next synchronization. In this case,
buffering could actually increase the total network traffic instead
of decreasing it.
<H4>Buffering Techniques</H4>
<P>
The lower half of the Technical Settings screen (shown previously
in Figure 5.4) contains the controls for buffer settings. If you
create a table, you have complete control over these settings.
To change these settings on a SAP table, you need to obtain a
modification key from SAP.
<P>
You can set the buffering for a table when you create it, or you
can change it later. Changing the buffer settings on SAP tables
requires a modification key, which you can obtain from SAP.
<P>
These three radio buttons switch buffering off and on:
<UL>
<LI>Buffering Not Allowed
<LI>Buffering Allowed But Switched Off
<LI>Buffering Switched On
</UL>
<P>
Choose Buffering Not Allowed if the table should never be buffered,
which occurs in the following cases:
<UL>
<LI>Users must always have 100 percent up-to-the-second accurate
information for both reads and writes. This might be the case
for very sensitive queries such as stock market quotations or
for real-time control systems such as goods movements on warehouse
floors.
<LI>Records from the table are updated as often as they are read,
causing buffering to be unsuitable (see below).
</UL>
<P>
Choose either Buffering Allowed But Turned Off or Buffering Turned
On if the users of this data can tolerate a 1-to-4 minute buffer
latency. Don't forget this latency will not exist when updating
data because you will code <TT>bypassing buffer</TT> to get the
latest information.<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>
Buffering Not Allowed on a SAP table means you should not turn buffering on for this table. Doing so can cause unreliable operation of R/3 applications and possible loss or corruption of data.</BLOCKQUOTE>

</TD></TR>
</TABLE>
</CENTER>
<P>
<H4>Buffering Type</H4>
<P>
As shown on the Technical Settings screen in Figure 5.4, three
types of buffering are possible:
<UL>
<LI>Full buffering
<LI>Generic buffering
<LI>Single-record buffering
</UL>
<P>
Although you use a check box to indicate the buffering type, only
one type can be selected at a time. If you choose more than one,
an error message will be displayed.
<P>
There are two data buffers on each application server, and the
buffering type chosen determines which buffer is used. On an application
sever there are:
<UL>
<LI>The generic record buffer
<LI>The single-record buffer
</UL>
<P>
The generic record buffer is called <TT>TABL</TT> (short for &quot;table&quot;).
The single-record buffer is <TT>TABLP</TT> (&quot;P&quot;' stands
for &quot;partial&quot;).
<H5>Full Buffering</H5>
<BLOCKQUOTE>
To activate the full buffering type, tickmark the Full check box.
When an attempt is made to read data from a fully buffered table,
the system looks in the <TT>TABL</TT> buffer for it. If it is
not found there, <I>all rows</I> are loaded from the database
into <TT>TABL</TT> (see Figure 5.17). This happens whenever a
<TT>select</TT> statement for it is executed, no matter how many
records match the <TT>where</TT> clause. Even if no records match,
all are loaded into the buffer if the table is not already there
or if it has been invalidated due to buffer synchronization.
</BLOCKQUOTE>
<P>
<A HREF="javascript:popUp('f5-17.gif')"><B>Figure 5.17:</B> <I>All rows of a fully buffered table are
loaded into TABL</I>.</A>
<BLOCKQUOTE>
Loading of <TT>TABL</TT> does not occur with <TT>select single</TT>
statements; only <TT>select/ endselect</TT> does this. If the
table is fully buffered and a <TT>select single</TT> statement
is executed, no records are loaded into <TT>TABL</TT>. However,
if the table is already loaded into <TT>TABL</TT>, <TT>select
single</TT> will read records from it.
</BLOCKQUOTE>
<BLOCKQUOTE>
During buffer synchronization, the entire table is invalidated
if any record within it changes. The next time data is read the
entire table is reloaded.<BR>
</BLOCKQUOTE>
<CENTER>
<TABLE BORDERCOLOR=#000000 BORDER=1>
<TR VALIGN=TOP><TD WIDTH=600><B>TIP</B></TD></TR>
<TR VALIGN=TOP><TD WIDTH=600>
<BLOCKQUOTE>
If a <TT>select </TT>statement is executed but quite often does not find data in the table, full buffering can still make the table accesses more efficient. Because the entire table is in the buffer, the system can determine whether the records exist before going to the database, thus avoiding a database access to find out.
</BLOCKQUOTE>

</TD></TR>
</TABLE>
</CENTER>
<P>
<BLOCKQUOTE>
Full buffering is appropriate for small tables that seldom change.
Check tables and their text tables, such as <TT>ztxt005</TT>,
<TT>ztxt005t</TT>, <TT>ztxt005s</TT>, and <TT>ztxt005u</TT>, should
be fully buffered. They are set up with an initial set of valid
values and descriptions and modified infrequently thereafter.
</BLOCKQUOTE>
<H5>Generic Buffering</H5>
<BLOCKQUOTE>
With generic buffering, a <I>group</I> of records is loaded into
<TT>TABL</TT> instead of the entire table. To activate this type
of buffering, tickmark the Generic check box and put a number
<I><B>n</B></I> in the No. of Key Fields so that the <I>n</I>
left-most fields of the primary key will group records. When a
record is read and <I>n</I> is 1, all records having the same
value in the <I>first</I> field of the primary key are loaded
into the buffer. When a record is read and <I>n</I> is 2, all
records having the same value in the <I>first two</I> fields of
the primary key are loaded into the buffer. This is illustrated
in Figure 5.18.
</BLOCKQUOTE>
<P>
<A HREF="javascript:popUp('f5-18.gif')"><B>Figure 5.18:</B> <I>Generic buffering. n must be less than
the number of fields in the primary key</I>.</A>
<BLOCKQUOTE>
In another example, suppose you choose generic buffering for table
<TT>ztxlfa1</TT> and set the No. of Key Fields to 1. Because the
first field is <TT>mandt</TT>, all records for a client are loaded
into the buffer at one time.<BR>
</BLOCKQUOTE>
<CENTER>
<TABLE BORDERCOLOR=#000000 BORDER=1>
<TR VALIGN=TOP><TD WIDTH=600><B>NOTE</B></TD></TR>
<TR VALIGN=TOP><TD WIDTH=600>
<BLOCKQUOTE>
If you specify full buffering for a client-dependent table (having <TT>mandt </TT>in the first column), the system automatically buffers it generically with n equal to 1. That is, when a record is read, only records having the same client number are loaded into the buffer. You cannot see this reflected in the technical set-tings; they continue to indicate full buffering. It just happens &quot;under the covers.&quot;
</BLOCKQUOTE>

</TD></TR>
</TABLE>
</CENTER>
<BLOCKQUOTE>
</BLOCKQUOTE>
<BLOCKQUOTE>
Generic buffering is suitable for tables in which records are
usually accessed in sets or groups. It is suitable if, when one
record of the group is accessed, more accesses will usually occur