The errata list is a list of errors and their corrections that were found after the product was released.
The following errata were submitted by our customers and have not yet been approved or disproved by the author or editor. They solely represent the opinion of the customer.
| Version |
Location |
Description |
Submitted by |
Date submitted |
| Printed |
Page xiii
Preface |
There are examples for the book, which is not noted in the Preface in the "How to Contact Us Section." Perhaps a section on where to
find the examples can be included.
{online Chapter 1} In the online sample chapter (no pages or page
numbers), there are two typos I detected:
1. Figures 1-5 is wrong; it's a duplicate of Figure 1-6.
2. "BASIS tablespaces" section incorrectly includes BTABD, STABD.
|
Anonymous |
|
| Printed |
Page 1
|
The acronym "SAP" nowadays (since 1976!) means (in German) "Systeme, Anwendungen, Produkte in der Datenverabeitung"
(in English):
"Systems, applications, products in data processing"
The term "Systemanalyse und Programmentwicklung" was only used
between 1972 and 1976, after the firm was founded.
|
Anonymous |
|
| Printed |
Page 9
|
The DB-ID does not always begins with "SA." If this were true, there would only be 35 different SIDs (0-9 and A-Z except P-SAP,
which is never allowed). In any of the Installation Guides SAP R/3,
the section "Installation Preparations - Choosing the SAP System
Name" mentions all necessary conventions . . . the one you used
is not found there. (Important: DB-ID is always SAP-ID.)
|
Anonymous |
|
| Printed |
Page 9
Last paragraph |
The statement, "SAP mandates that the Oracle SID ... always begin
with an uppercase "SA" ..." is incorrect. SAP requires that the Oracle
SID be the same as the R/3 SID. The R/3 SID must be 3 characters,
uppercase, begin with a letter, and not be a name reserved by SAP;
there is no requirement that it begin with "SA".
|
Anonymous |
|
| Printed |
Page 10 & 11
|
The Basis tablespace PSAPDICD or PSAPDICTD does not exist in a standard SAP R/3 installation. The correct name for the
tablespace, that hosts the SAP data dictionary tables, is PSAPDDICD.
The tablespaces PSAPVB0101D, PSAPVB0102D, PSAPVB0201D, PSAPVB0202D
do not exist in a standard R/3 installation. But the author forgot
to mention the "release tablesapaces" PSAPEL<rel>D/PSAPEL<rel>I and
PSAPES<rel>D/PSAPES<rel>I, where <rel> means release (eg 40B or
45B); S = sources (development environment), L = loads (development
environment). The contents of these tablespaces are (almost) static
(programs), so there is no "high write activity."
|
Anonymous |
|
| Printed |
Page 11
Figure 1-4. Standard SAP tablespaces |
In the box for PSAPSTABD the words "High write activity" are included.
As indicated this tablespace holds master data and therefore will have a
higher READ activity. This statement could cause some to configure their
disk for high write activity instead of high read. The reason I did not
categorize this as a serious technical mistake was because the tablespace
was correctly described on page 12, 2nd paragraph as containing primarily
referenced (i.e. High Read) information.
|
Anonymous |
|
| Printed |
Page 14
Under the heading "Oracle system files" |
It is impossible to have two data files (in your example: psappoold.
data1) with the same name. The naming convention for the Oracle
datafiles is wrong. The correct naming would be:
/oracle/SID/sapdata1/pooli/pooli.data1
Following SAP naming convention, one is not allowed to change these
namings.
|
Anonymous |
|
| Printed |
Page 23
|
The location for the SAPDBA executable program is wrong. The correct (standard) location can be found in:
/usr/sap/SID/sys/exe/run
|
Anonymous |
|
| Printed |
Page 31
|
SM51 does not give a "list of defined SAP users" (this would either be AL08 or SM04 = all currently connected users, either
systemwide (AL08) or application-serverwide (SM04). SM51 gives you
a list of all application servers comprising one R/3 system.
|
Anonymous |
|
| Printed |
Page 33
Figure 2-13 |
Figure 2-13 seems to have undergone some little clearing here and there, but I have minor problems with the amount of "total size
tablespaces" (which has a value of 28.010.200 Kbytes) and the "total
size tables and indexes" (which has a value of 81.677.364 Kbyte).
How is this possible? Did the author use a special zipping algorithm?
And by the way, the database is 55% free, not 55% full. This is
clearly stated on the screenshot.
|
Anonymous |
|
| Printed |
Page 40
|
The correct name for the INIT.ORA-file in a SAP R/3 environment is always:
/oracle/SID/dba/initSID.ora
|
Anonymous |
|
| Printed |
Page 54, 146
First paragraph under heading "Using SAP with RAID" |
I have now read many Installation guides and NEVER have I seen it say that
RAID-5 is too slow for most SAP applications. Please show me an OSS note
and/or installation guide that indicates this as I'm very interested in seeing
this.
This is repeated on Page 146 under the heading of "RAID Issues," where it
states: "In a nutshell, SAP AG does not recommend using RAID-5 because of the
slowdown associated with a high-update process, and instead favors RAID-1
(disk mirroring)...". Again, where does SAP state this?
|
Anonymous |
|
| Printed |
Page 91
Example 4-14 |
Example 4-14 now reads
select substr(a.tablespace_name, 1,12) tablespace,
count(*) count
from v$session a, dba_data_files a
where b.row_wait_file# = a.file_id
and row_wait_file# <> 0
and type = 'USER'
and event = 'db sequential read waits'
group by substr(a.tablespace_name, 1,12)
The field 'event' does not exist in either of the tables
(v$session or dba_data_files). This results in the SQL failing
to run. The same problem exists in Examples 4-13 and 4-15. I am
running oracle v8.0.5 on Linux and 8.0.4 on Solaris.
|
Anonymous |
|
| Printed |
Page 111
Examples 5-6 and 5-7 report tables with chained rows. |
The method of identifying tables that would benefit from a
reorganistation is based on these two scripts.
The first reports tables without RAW or LONG RAW. The second
reports tables with RAW or LONG RAW.
It then suggests that only tables listed in the first report
will benefit from a reorg, as the second report list tables that
often contain records that are larger than the database block
size - which will always be chained!
What is the argument for splitting the chained rows reports in
this way?
Is the correct way not to split the reports by LONG or LONG RAW
columns? i.e. columns that can contain 2Gbytes of data, as
opposed to RAW which has a maximum of 2K.
This would mean that the first report lists tables without LONG
or LONG RAW, and the second the opposite.
|
Anonymous |
|