Oracle SAP Adminstration by Donald K. Burleson Unconfirmed error reports are from readers. They have not yet been approved or disproved by the author or editor and represent solely the opinion of the reader. If you have technical questions or error reports, you can send them to booktech@oreilly.com. Please specify the printing date of your copy. This page was last updated April 10, 2001. Here's a key to the markup: [page-number]: serious technical mistake {page-number}: minor technical mistake : important language/formatting problem (page-number): language change or minor formatting problem ?page-number?: reader question or request for clarification UNCONFIRMED errors and comments from readers: (xiii) 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. {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. {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.) {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". {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" PSAPELD/PSAPELI and PSAPESD/PSAPESI, where 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." {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. {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. {23} The location for the SAPDBA executable program is wrong. The correct (standard) location can be found in: /usr/sap/SID/sys/exe/run {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. {33} 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. {40} The correct name for the INIT.ORA-file in a SAP R/3 environment is always: /oracle/SID/dba/initSID.ora [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? ?91? 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. [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.