What is SAP BASIS?

- SAP Basis: Provides the runtime environment for all SAP applications Optimally embeds the application in the system environment Defines a stable architecture framework for system enhancements Contains the tools for administering the entire system Allows the distribution of resources and system components Provides interfaces for decentralized system parts and external products. What is a Client? - A client is, in organizational terms, an independent unit in the R/3 System. Each client has its own data environment and therefore its own master data and transaction data, assigned user master records and charts of accounts, and specific customizing parameters. A user master record linked to the relevant client must be created for users to be able to log on to the system. Examples of client-specific data include: User master data such as parameters, authorization, user groups Customizing data such as organizational units, assignments, and document types Application data such as business transaction data, and material master data Changes to Repository objects are client-independent, and immediately affect the runtime environment. Therefore, changes have to be tested before being transported to the production system. What is a Role? -A role describes a set of logically linked transactions. These transactions represent the range of functions users typically need at their workstations. What is a Dispatcher? -The central process in the R/3 application layer is the dispatcher. Together with the operating system, the dispatcher controls the resources for the R/3 applications. The main tasks of the dispatcher include distributing transaction load to the work processes, connecting to the presentation layer, and organizing communication. During initialization of the R/3 System, the dispatcher executes the following actions, among others: it reads the system profile parameters, starts work processes, and logs onto the message server (this service will be explained later). User screen input is received by the SAP presentation program SAP GUI, converted into its own format, and then sent to the dispatcher. The processing requests are then saved by the dispatcher in request queues and processed according to first in / first out. The dispatcher distributes (dispatches) the requests one after the other to the available work processes. Data is actually processed in the work process. The user that sent the request through the SAP GUI is usually not assigned the same work process, because there is no fixed assignment of work processes to users.

What are the Processes? - The operating system views the R/3 runtime system as a group of parallel, cooperating processes. On each application server these processes include the dispatcher as well as work processes; the number of work processes depends on the available resources. Work processes may be installed for dialog processing, update, dialog free background processing and spooling. In addition to these work process types (dialog processing (D), update (V: for the German Verbuchung), lock management (E), background processing (B), spool (S), the R/3 runtime system provides two additional services for internal and external communication (below are the restrictions on the number of work processes): The message server (MS or M) communicates between the distributed dispatchers within the R/3 System and is therefore the prerequisite for scalability using several parallelprocessing application servers. The gateway server (GW or G) allows communication between R/3, R/2 and external application systems. Dialog: Every dispatcher requires at least two dialog work processes Spool: At least one for each R/3 System (more than one allowed for each dispatcher) Update: At least one for each R/3 System (more than one allowed for each dispatcher) Background processing: At least two for each R/3 System (more than one allowed for each dispatcher) Enqueue: Only one enqueue work process is needed for each system

What is rdisp_max_wprun_time? - Dialog work processes should not be loaded down with long-running dialog steps, as these work processes would then not be available to other users. The remaining dialog work processes would have to handle many more users, thus considerably increasing response times. This is the reason for the parameter rdisp/max_wprun_time (default setting: 300 seconds), which sets the maximum time a dialog step is allowed to remain in a dialog work process. If this time is exceeded by more than double, the dialog step is terminated and the started transaction terminates with an error. This allows the administrator to ensure that users execute long-running actions only in the background work processes, which are designed for these types of long-running actions.

What is an Instance? -An instance is an administrative unit that combines R/3 System components providing one or more services. The services provided by an instance are started or stopped together. You use a common instance profile to set parameters for all the components of an instance. A central R/3 System consists of a single instance providing all the necessary R/3 System services. Each instance has its own SAP buffer areas.

The

example illustrates how an additional background processing server (a) and dialog server (b) are set up. These instances, which provide specific services, generally run on separate servers, but can also run on the same server, if needed. The message server provides the application servers with a central message service for internal communication (for example, trigger update, request and remove locks, trigger background requests). The dispatchers for the individual application servers communicate through the message server, which is installed once in each R/3 System (it is configured in the R/3 System profile files). Presentation servers can also log on to an application server through the message server. This means that you can use the message server performance database for automatic load distribution (logon load balancing). An R/3 instance is a group of R/3 services that are started and stopped as a unit (by an R/3 dispatcher) and have a common instance profile. The name of an R/3 instance is composed of letters standing for the relevant services, and an instance number which is unique for each computer. The services may be D, V, E, B, M, G, or S, which respectively stand for dialogue, update, enqueue, background, message, gateway, and spool services. A central instance is an R/3 instance which contains the message service, and typically contains all R/3 Services (and is named, for example, DVEBMGS00). A central system is an R/3 System consisting of an RDBMS service and the central instance. A dialogue instance is an R/3 instance consisting of dialogue work processes.

What are the types of RFC Calls? - There are three types of RFC calls: Synchronous RFC call: The calling program stops until the function module has been processed on the target server and any results have been returned to the caller. Only then does the calling program continue processing. Asynchronous RFC call: The calling program runs parallel to and independently of function module processing in the target system. Programmers are responsible for the processing of the results. In addition, the target system must also be available at the time of the RFC call. Transactional RFC call: Several function modules can be grouped into one transaction. They are processed only once in the target system, within an LUW, and in the sequence in which they were called. In the case of an error, a message is sent to the calling system that you can analyze using transaction SM58. For transactional RFC, the target system does not have to be available at thetime of the RFC call. In addition, you can configure the frequency and intervals of individual queries.

How does a SAP LOGON work? - When a SAP GUI process is started on the front end, a command line parameter is sent, indicating one of the following: A specific dispatcher can be accessed directly (go directly to 3) The logon must first be sent to the message server (1) for logon load balancing

When

logon load balancing is used, the message server returns the IP address and instance number (2) of a specific dispatcher. The number of dispatchers available for a particular logon is configured in the system. Logon load balancing is useful if certain user groups are assigned to work on specific servers. The message server returns the IP address of one of the assigned dispatchers, for example the dispatcher that has shown the best response time during the last five minutes. Response times are stored in the collected workload data. The frontend process then connects to the assigned dispatcher (3), which selects a free dialog work process (4) to compare the logon user data with the user data stored in the database (5, 6). If the logon user data does not agree with the stored user data, no logon is allowed. If the logon is successful, the SAP GUI is established with the user (7-10). This dispatcher and its work processes are used for the duration of the session. If a user logs off and then logs on again to the system, logon load balancing may cause the message server to select another dispatcher for the user to work with.

How does startsap work in UNIX? - Script startsap calls program SAPSTART. Program SAPSTART reads the START PROFILE and starts the R/3 components and/or services listed in /usr/sap/<SID>/SYS/profile/START_<instance>_<hostname>. On a central instance, SAPSTART starts the message server, dispatcher, collector, and the sender. On a dialog instance, only the sender and the dispatcher are started. The collector and sender are used to implement the central R/3 System log. The dispatcher forks and creates child processes: The work processes (dialog, background, spool, update, . . .) are created according to the information in the profiles /usr/sap/<SID>/SYS/profile/<SID>_<instance>_<hostname> and /usr/sap/<SID>/SYS/profile/DEFAULT.PFL. The gateway reader. This does not depend on the profiles, and it is always started. All the work processes except the gateway reader connect to the database. What is CCMS? - The Computing Center Management System (CCMS) is an integral part of the R/3 Basis. CCMS provides tools for managing: R/3 System and performance Database and archiving Workload Output Security You can use the CCMS to analyze and distribute client workloads and report on resource consumption for system components. The CCMS also provides graphical monitors and management utilities. CCMS provides 24-hour unattended system management functions from within R/3 through operation modes and instances.

What are Operation Modes? - Typically, customers require more dialog processes during the day and more background processes during the night. To adjust the proportions of the various R/3 work processes to suit different phases of system activity, you can: Maintain the instance profile and restart the system (for unusual changes) Define operation modes and use the operation mode switch (for daily changes) Operation modes optimize system resources for different phases of system activity. Operation mode switching reconfigures your R/3 System dynamically, so you do not need to change the instance profiles for your server and you experience no system downtime. An operation mode configures the use of resources for all the instances in your R/3 System based on: The services or work processes you need The time interval you choose

How to configure STMS? - The TMS configuration includes the following steps: Configuring the transport domain: You must define which R/3 Systems in the system landscape should be combined in a transport domain and which R/3 System is to be the transport domain controller The transport control program requires a transport profile that contains information about establishing the database connection for all R/3 Systems in the transport domain. TMS generates and manages this transport profile as a part of the transport domain configuration. You do not have to adjust the transport prof ile using operating system functions. Configuring the transport routes: The transport routes are used to define in which target system you want to consolidate and deliver change requests. The transport control program requires a transport profile that contains information about establishing the database connection for all R/3 Systems in the transport domain. TMS generates and manages this transport profile as a part of the transport domain configuration. You do not have to adjust the transport profile using operating system functions. This transport file is located in the subdirectory bin of the directory /usr/sap/trans. Naming convention: TP_<domain name>.PFL. To check the availability of the transport control program in an R/3 System, use Transaction STMS (System overview). Choose R/3 System Check Transport tool. A hierarchical list is displayed that shows the status of the individual checks. If you have not selected an R/3 System, the transport control program of all R/3 Systems in the transport domain is checked. To display the tp parameters of an R/3 System, in the STMS System Overview double -click on one R/3 system and select tab Transport tool. A list is displayed showing the parameters set in transport profile. To check the availability of the transport directory program in an R/3 System, call transaction STMS

(System Overview) and choose R/3 System Check Transport directory. Test files are created in the subdirectories of the transport directory and in the last step of the check removed. The configuration of the transport routes is managed in the R/3 System, which serves as the transport domain controller, and can be distributed to and activated in all other R/3 Systems connected in the transport domain. Before you can configure the transport routes, the following requirements must be met: The transport domain must be configured All R/3 Systems involved must be included in the transport domain The transport control program must be configured (is done automatically during the above steps) The transport route configuration consists of: System attributes Consolidation routes Delivery routes
The

global transport directory and all the necessary subdirectories are created during the installation of an R/3 System. Mount this directory using the operating system tools (nfs for UNIX; share for NT) for all systems within a system landscape or a transport group. The amount of disk space required depends on the amount of development work: estimate 10 MB for each customizer and developer. You will need additional space for client exports. The R/3 Parameter DIR_TRANS has to point to the path of the transport directory. For Unix, the default path is /usr/sap/trans. For Windows NT, the default path is \\$ (SAPTRANSHOST)\sapmnt\trans and you must define the transport host with the alias SAPTRANSHOST on the domain name server. The subdirectories required in the common transport directory include: bin: Configuration files for tp (TP_<DOMAINNAME>.PFL) and TMS (DOMAIN.CFG) data: Exported data olddata: Old exported data (to be archived or deleted) log: Transport logs, trace files, and statistics actlog: Action logs for all tasks and requests buffer: Transport buffer for the each system, indicating which transports are to be imported cofiles: Command or change request infrmation files that include information on the transport type, object classes, required import steps, and post-processing exit codes sapnames: Information pertaining to transport requests for each SAP user EPS: Download directory for advanced corrections and Support Packages tmp: Temporary data and log files

What are Client-Copies? SAP provides three tools for copying data between clients: Local client copy between clients in the same R/3 System Remote client copy between clients in different R/3 Systems Client transport between clients of different R/3 Systems Remote client copy and client transport differ according to the way in which data is transferred: In a remote client copy, data is transferred directly between the source and target client using remote function calls (RFCs) through a network connection. In a client transport, data is exported to a file at the operating system level. At some future time, the client is imported from the file system to the target system. When using the client copy tools, the data you can select to be copied includes: user master data, client-specific Customizing, and application data. R/3 Repository objects, such as ABAP programs, are not transported with the above tools. Development objects can only be transported using change requests. A local client copy copies between clients within the same R/3 System. Both a local and remote client copy must be initiated from the target client using the following steps: To create an entry for the target clie nt in the client maintenance table, choose Tools Administration Administration Client Admin. Client Maintenance. Log on to the target client as SAP* with the initial password PASS. Perform the client copy using the menu options found under Tools Administration Administration Client Admin. Client Copy. Select the data to be copied using a profile. Assign the source client for Customizing data, application data, and user master records. Begin the client copy. As copying is a lengthy process, use background processing. To ensure data consistency, you may not logon to the target client during a client copy. SAP also recommends that you do not work in the source client during a client copy. Note that SAP delivers the software with standard clients 000 and 001. You may not work in client 000, but may use client 001. However, SAP recommends that you begin R/3 implementation by creating a new client as a copy of client 000. A remote client copy allows you to copy between clients in different R/3 Systems.You can use a remote client copy to, for example, transport client-dependent as well clientindependent Customizing data between R/3 Systems. A remote client copy proceeds in the same way as a local copy, but sends the data through a remote function call (RFC) connection to the target client. A remote client copy is easy to use, and does not require file system space on operating system level. The limitations of a remote client copy are as follows: A remote client copy does not create a file at operating system level, so there is no "hard copy" of the client to be copied. Therefore, the same, identical client copy cannot be duplicated at a later date. As of 4.6A, cross-client Customizing objects are copied during a remote client copy.

To

be able to transport all data during the client copy, the structures of all copied or transported tables in both systems must be identical. During remote client copy, an automatic Repository consistency check is performed. If inconsistencies are detected, the client copy is terminated and an error message is displayed. A client transport differs from a remote client copy in that it does not use RFC. Like a remote client copy, however, a client transport is used to copy data between different R/3 Systems. A client transport consists of two steps. First, a client export extracts client data from the source client to files at the operating system level. Second, the data is imported from the operating system files into the target client. To perform a client export, proceed as follows: Log on to the source client. From the R/3 initial screen, choose Tools Administration Administration Client Admin. Client Transport Client Export. Select the data to be copied using a profile. Indicate the target system to which the client will be copied. (The target system must be defined in TMS as part of the transport domain.) Begin the client export. As copying is a lengthy process, use scheduled background processing. The client export performed in the source system <S-SID>, exports the client data asynchronously by calling the transport program tp at the operating system level. This export process will generate up to 3 data files at operating system level: RT< number >; this file contains client-specific data RO< number >; this file contains Cross-client data RX< number >; this file contains SAPscript texts Depending on the type of data selected through the client transport profile, the client copy command files added to the buffer of the target system are <S-SID>KO<number>; this file is for cross-client data <S-SID>KT<number>; this file is for client-specific data <S-SID>KX<number>; this file is also for client-specific data The client export change requests are not imported when an Import all takes place. Therefore, you must import these requests into the target client using TMS. You must import the data in the following order: first cross-client data, then client- specific data. After the import process has completed, post-import activities are required possible for object generation steps. After completing the import, log on to the target client. From the R/3 initial screen, choose Tools Administration Administration Client Admin. Client Transport Import Editing. To display client transport logs, use the Transport Organizer. During client transport, a Repository consistency check can be performed by clicking the RFC system check button in Transaction SCC8. If inconsistencies are detected, a list of the ABAP Dictionary tables definitions missing in the target system is generated. This will help your recognize in advance formal problems that may occur during the import of the source data. Note: The value for the parameter "rdisp/max_wprun_time" should be increased; the recommended value is 1800 seconds. If copying is unexpectedly terminated, the system uses the name of the table being currently copied to restart the copy process.

All log files are physically stored in the transport log directory at operating system level. Log files are named CC<number>.<SID> , where <number> is the serial client copy number, and <SID> is the source system ID. Client copies ignore tables in the local development class $TMP. If you want to copy these tables,modify the development class in the object directory. Deleting a client entry with client maintenance (Transaction SCC4) allows you to temporarily lock the client. The deletion procedure preserves the data for the client but prevents users from logging on to the client or accessing the data belonging to the client. To restore the client and allow logon, recreate the client entry using client maintenance.

What is a SAPROUTER? - SAProuter is a program that serves as an intermediate station between R/3 Systems or programs. SAProuter acts as an application level gateway (proxy) and can be implemented independently of an R/3 System directly on a firewall. SAProuter enables you to completely control access to your R/3 System(s). The network interface (NI) is a separate, platform-independent, intermediate layer developed by SAP. The NI layer forms the upper part of the transport layer in the OSI 7 layer model. SAProuter as well as all R/3 CPI-C and RFC programs use this layer. SAProuter uses a configurable a route permission table to allow or deny connections from other systems. You can use SAProuter to: Control and log the connections to your R/3 System Allow access from only the SAProuters you have selected Protect your connection and data from unauthorized access Only allow encrypted connection from a known partner (using the SNC layer) During installation, SAProuter is normally located in directory /usr/sap/<SID>/SYS/exe/run (UNIX). SAP recommends that you create the subdirectory saprouter in the directory /usr/sap, because the /exe/run dir. will be overwritten by the new kernel functions during an R/3 Release upgrade, thus destroying your SAProuter configuration. Under Unix, you can start SAProuter from the script startsap. Under Windows NT, it is recommended to define the service. SAP also recommends downloading the most recent version from any sapserv system. SAP recommends that the route permission table be maintained in /usr/sap/saprouter/saprouttab (UNIX). If you wish to place this table in another directory or under a name other than saprottab, specify the location using the option saprouter -r. A route string describes the stations of a connection required between two hosts. Each route string has a sub-string for each SAProuter in between, and for the target server. The syntax for the sub-strings are: /H/ = indicates the host name. /S/ = an optional entry used for specifying the service port. The default value is 3299. /W/ = indicates the password for the connection. The default is , no password. In the example shown here, the connection from the customers frontend PC computer1 to SAPs application server APPSERVER is set up in three steps: 1. computer1 sets up the connection to customer_saprouter according to the first substring.

2. customer_saprouter uses the route permission table to check whether the connection is allowed. This sets up the connection between both SAProuters. 3. sap_saprouter checks whether the route from customer_saprouter to the application server is allowed. The password is also checked. sap_saprouter then sets up the connection to the application server APPSERVER. A route permission table (saprouttab) must be defined for each SAProuter. The route permission table contains the host names, port numbers, and passwords of a source and destination host. Each time an access is requested, R/3 looks for table saprouttab in the working directory of the SAProuter. If no route permission table is found, SAProuter terminates with an error message. To create a route permission table, use a standard text editor. The route permission table contains a maximum of five fields for each possible access: Permit/Deny/Secure, Source computer, Target computer, Service, and Password When making entries in these fields, you can use wildcards (*). However, these should be used with caution. In the example shown here, all computers with IP addresses beginning with 123.45.67 do not need a password to communicate with all of the services on target computers with host addresses (IP address) beginning with 123.45. If the first field displays a D instead of a P, access to the specified computer and its services has been denied. If you leave the service and password blank, the defaults are used. For service the default is 3299; if the field Password is blank, no password is required. When checking accesses, SAProuter looks for the first appearance of a Permit or a Deny for one specific computer. Once this is found, the rest of the route permission table is not checked for this computer. When you configure the route permission table, specify all deny entries before permits. Step 1: In Window 1 ( host 1) start SAProuter by entering command saprouter -r. This command starts SAProuter without parameters. For a complete list of SAProuter commands, search for saprouter in the Online help. Step 2: In Window 2 (host 2), start the test program niping to emulate a server by entering command niping -s. Step 3: In Window 3 (host 3), start the test program niping to emulate a client, by entering command niping -c -H host2. This command tests the connection without SAProuter, that is, it tests the connection directly between host 2 and host 3. Step 4: In Window 3, restart the test program niping by entering the command niping -c H /H/host1/H/host2. This command tests the connection with SAProuter. A host name is interpreted as a route through one or more SAProuters to the server if the host name is preceded with /H/. In steps 3 and 4, several data packets are sent to the server and then returned by the server. To stop all active niping servers and clients, enter command niping -t. The main SAProuter commands are: saprouter displays a complete list of the SAProuter parameters (this includes all options and examples of a route permission table). saprouter -r starts program SAProuter. saprouter -s stops program SAProuter.

The

trace level can be set to 1 to 3 (1 being lowest detail and 3 being the highest). The default destination for the trace file is dev_rout in the work dir. You can specify the trace to another file by setting the -T option. For logging connections, you can specify a log file when starting your SAProuter. To do this, use the option -G, for example, saprouter -r -G <log file>. All important actions such as connection start, run-time operations, are logged to the file: Connection from (client name / address) Connection to (partner name / address) Partner service Start time/end time Connection requests rejected by the route permission table

ORACLE
Oracle mechanisms move the entire database security mechanism to the operating system level. If the user OPS$<user_name> is defined as identified externally at the database level, the operating system user <user_name> can connect to the database without authentication. The following OS and database users are available for Oracle administration in an R/3 System: UNIX: ora<SID> (no OPS$ user), <SID>adm, and OPS$<SID>adm Windows NT: <SID>adm, OPS$<SID>adm and SAPService<SID>, OPS$SAPService<SID> The following OS groups are important in an Oracle database environment (see also Appendix): dba (NT: ORA_<SID>_DBA): OS users of this group can connect to Oracle using CONNECT INTERNAL with full database administration privileges oper (NT: ORA_<SID>_OPER): OS users of this group can connect to Oracle using CONNECT INTERNAL with restricted database privileges, such as startup or shutdown database The database administration tool SAPDBA requires the restricted database administration privileges available in the group oper. SAPDBA only has access to the tables required for performing R/3 database administration in the background. These privileges are assigned during R/3 installation or upgrade. The following mechanism is used by an R/3 work process to connect to the database as user SAPR3: A connection to the database is made as user OPS$ (UNIX: OPS$<SID>adm, NT: OPS$SAPService<SID>) with very few privileges.

User OPS$ is the owner of table SAPUSER. From this table, the password for user SAPR3 is retrieved and the database session for user OPS$ is terminated. The work process now connects as user SAPR3 with the password from table SAPUSER. To allow R/3 work processes to connect over the network using the OPS$ mechanism, the init<SID>.ora parameter REMOTE_OS_AUTHENT must be set to TRUE. This allows remote OS authentication for OS users with an OPS$ user on any computer in the network in which the database is accessible. To change the password of user SAPR3, perform the following: For UNIX: Use program SAPDBA to perform the required actions For NT: Connect to Oracle as user OPS$SAPService<SID>, and: Change the password entry for user SAPR3 in table SAPUSER Change the password of user SAPR3 As of version 4.5B, user SAPR3 is stored with an encrypted password in table SAPUSER. If an R/3 instance is running on a server other than the database server, R/3 work processes and their dedicated shadow processes communicate over a network. As communication protocol, TCP/IP is used. The work processes of an R/3 instance configured on the database server use the IPC protocol to communicate with dedicated shadow processes running on the same server. For Net8 to accept connections on the database server, the listener must be running. The Oracle utility lsnrctl is used to start and stop the listener and to check the status of Net8 connections. In a UNIX environment, the process tnslsnr is started. On NT, the service "OracleTNSListener" is started. Three operating system files are used in a NET8 configuration. You can find these files in the ORACLE_HOME subdirectory network/admin (NT: net80\admin) on each application server and on the database server: tnsnames.ora: Contains a list of service names for all databases that can be accessed in the network sqlnet.ora: Contains client side default domain information and optional diagnostic parameters used for client tracing and logging listener.ora :Only used on a database server machine. Contains Oracle system IDs for which the listener can receive connections, and various control parameters used by program lsnrctl The default R/3 System profile should contain the entry dbs/ora/tnsname = <SID> In a production database system, the database must always run in ARCHIVELOG mode and have the archiver process (ARCH) started (init<SID>.ora: log_archive_start = TRUE). ARCH archives a completed online redo log file into an offline redo log file in the archive directory. ARCH determines the archive directory from the init<SID>.ora parameter log_archive_dest (default: ?/saparch/) and determines the file name from the parameter log_archive_format. Once the offline redo log file has been successfully created, the corresponding online redo log file is released to be overwritten with new log information. If no freespace is available in the archive directory, the archiver does not archive the file. After a corresponding number of redo log switches, the database becomes "stuck". Database changes cannot be committed as long as this archiver stuck situation persists.

A tablespace in an Oracle database consists of one or more physical data files. A data file can be associated with only one tablespace. You can increase a tablespace in two ways: Add a data file to a tablespace. When you add another data file to an existing tablespace, you increase the amount of disk space allocated for the corresponding tablespace. Increase the size of a data file. Storage parameters such as INITIAL EXTENT, NEXT EXTENT and MAX EXTENT allow you to manage space allocated to a table. For performance reasons, operating system block size should be the same as Oracle data block size. The objects located in the tablespaces SYSTEM, PSAPROLL, and PSAPTEMP belong either to the Oracle database users SYS or SYSTEM. Do not create any objects owned by other users in these tablespaces. The objects located in the other tablespaces belong to the R/3 database user SAPR3. R/3 System users do not have a database system user. Directory and file names are standardized in the R/3 environment. We recommend that you use the following standards: Tablespace files reside in the sapdata<n> directories The online redo log files reside in the origlog and mirrlog directories The offline redo log files are written to the saparch directory There should be at least 3 copies of the Oracle control file on different disks The profile init<SID>.ora configures the Oracle instance, and resides in directory dbs (NT: database) The profile init<SID>.sap configures the backup tools brbackup and brarchive, and resides in directory dbs (NT: database) The profile init<SID>.dba configures the SAPDBA tool, and resides in directory dbs (NT: database) The Oracle alert file is written to directory saptrace/background Trace files of the Oracle shadow processes are written to the directory saptrace/usertrace During reorganization, export datasets are written to directory sapreorg The directories saparch, sapcheck , sapreorg, and sapbackup are used by the SAP database tools. The Oracle database file tree structure on the database server site has two main branches: The Oracle binaries are located in the subdirectory bin of the ORACLE_HOME directory. The environment variable ORACLE_HOME points to this directory. The ORACLE_HOME directory is also required on each server with a database client The environment variables SAPDATA_HOME and SAPDATA<n> point to the directories containing database-specific files, such as data files, online redo log files, and offline redo log files The operating system users <SID>adm and ora<SID> (on the database server, not used in an NT environment) require the following environment variables: ORACLE_SID = <SID> (on the database server site) DBS_ORA_TNSNAME: set to the database identifier <SID> from tnsnames.ora In a UNIX environment, the following environment variables are set by R/3 configuration tools:

ORA_NLS: $ORACLE_HOME/ocommon/NLS_723/admin/data (on each client site) ORA_NLS32 $ORACLE_HOME/ocommon/NLS_733/admin/data (on each client site) ORA_NLS33: $ORACLE_HOME/ocommon/NLS_805/admin/data (on each client site)

When a problem occurs, run sapdba -check and check the log file in directory sapcheck . To begin troubleshooting, you can check the R/3 System log or the following Oracle files: The Oracle alert log file ORACLE_HOME/saptrace/background/alert_<SID>.log, which often contains further information, such as the ORA-XXXX return code that may identify the problem The Oracle background process trace files in directory saptrace/background The Oracle user trace files in directory saptrace/usertrace The startdb.log file in the home directory of user <SID>adm, which contains error information in the case of database instance startup failure To check the R/3 System log, use transaction SM21. You should also search for related SAP Notes in SAPNet. If you cannot find an applicable SAP Note, create a customer message in SAPNet, and provide the SAP hotline with the following information: Syslog messages and the short dump (transaction ST22) related to the error Error messages from the Oracle alert log file Error messages from the Oracle background process and user trace files Error messages from the file startdb.log Log files of SAPDBA or BR* tools

The ten most frequent problems that occur when R/3 is installed on an Oracle database are: An archiver stuck situation The incorrect tape size on tape drives with hardware compression A missing end backup A tablespace overflow A table or index reaching its MAXEXTENTS limit ORA-1555, snapshot too old Net8 TCP/IP delay ORA-1578, data block corruption ORA-600, internal database error Poor performance of the cost-based optimizer The database of a production system should always be operated in ARCHIVELOG mode with an active Archiver process. When the database is in ARCHIVELOG mode, an online redo log file can only be reused after it has been completely archived to the offline redo log archive directory saparch. If the directory saparch is full, the online redo log files cannot be completely archived, and the

database will enter the archiver stuck state. This means that no further changes are possible to the system. If this occurs, the Oracle error message ORA-255 or ORA-272 is written to the database alert log. The following is an example of the Oracle alert log file alert_<SID>.log: Tue May 19 10:25:11 1998 ORA-00255: error archiving log 11 of thread 1, sequence # 1337 ORA-00312: online log 11 thread 1:'/oracle/TC1/origlogA/log_g11m1.dbf ORA-00312: online log 11 thread 1: '/oracle/TC1/mirrlogA/log_g11m2.dbf ORA-00334: archived log: '/oracle/TC1/saparch/TC1arch1_1337.dbf ORA-19502: write error on file "/oracle/TC1/saparch/TC1arch1_1337.dbf" When an archiver stuck situation occurs, the R/3 Systems hangs, and you cannot perform transactions until the online redo log file has been completely archived to directory saparch. To avoid an archiver stuck situation: Reserve some disk space by creating a dummy file in the archive directory saparch. Make the size of the dummy file five times the size of the offline redo log file. If saparch becomes full, remove the dummy file and run BRARCHIVE immediately. If BRARCHIVE is scheduled to run daily, ensure that saparch has enough disk space to hold at least three times the amount of the daily offline redo log files. Monitor how full saparch is. Check the file init<SID>.ora to see if parameter log_archive_start = true. Check if user ora<SID> has write authorization to saparch. Warning: Do not delete or move files from the archive directory saparch.

If you back up a tablespace online without RMAN, the tablespace must be in begin backup mode during the backup. This ensures that the Oracle data file headers of the data files belonging to the tablespace in the online backup mode are not updated. If a tablespace is in begin backup mode and the command shutdown immediate is issued in SAPDBA, SAPDBA puts every tablespace into end backup mode before the database is shutdown. If a tablespace remains in begin backup mode and the command shutdown immediate is issued in svrmgrl (or command stopsap db is issued), the database returns error ORA-1149 (missing end backup). To check which tablespaces are still in begin backup mode, use SAPDBA and choose DB Check verification DB System Check. The system then prompts the user whether SAPDBA should set the end backup automatically. If the database crashes during an online backup, or is powered down, or is shutdown by using shutdown abort, some tablespaces may remain in the begin backup mode. In this situation, because the tablespaces are in online backup mode when you try to open the database, error ORA-1113 is returned. For ORA-1113, you must perform a database recovery. To perform the recovery, use SAPDBA and choose Partial restore and complete recovery database. If a missing end backup error occurs, you do not need to restore any data files.

The

missing end backup error does not occur if the backup is performed with RMAN. If an extent of a given size is required in a tablespace, but there is not enough contiguous freespace available in the tablespace, Oracle returns error ORA-1653 (for tables) or ORA1654 (for indexes). The error messages are displayed in both the Syslog file and the ABAP short dump. To solve this problem, use SAPDBA to extend the tablespace with one extra data file. From the SAPDBA, choose Tablespace administration Alter tablespace Add Data file. If you extend several tablespaces, make sure that you place the data files on different disks, otherwise there may be problems with the I/O speed of disk access. You must perform a backup after every change in the file structure. If the number of extents allocated to an object reaches the maximum number specified in the MaxExtents storage parameter, then this object cannot request any more extents. When this maximum value is reached, Oracle reports error ORA-1631 (for tables) and ORA-1632 (for indexes). The error messages are displayed in both the Syslog file and the ABAP short dump. To avoid this problem: Monitor the number of extents regularly Run sapdba -next once a week Adjust the MaxExtents parameters as required To change the values of the next parameter for tables and indexes, run sapdba -next. To change the values of the MaxExtents parameter for tables and indexes, use the SAPDBA and choose Reorganization Alter/show table or index storage parameters Alter/show parameters. If the storage parameter MaxExtents is set to unlimited, the maximum number of extents is actually 2,147,483,645. Do not change MaxExtents to unlimited for all segments in your database. Do not set the MaxExtents to unlimited on rollback segments.

Oracle enforces statement-level read consistency. This ensures that the data returned by a single query is consistent with respect to the time when the query began. Therefore, a query never sees the data changes made by transactions that commit during the course of execution of the query. Usually, a long running query has error ORA-1555 if the data accessed by the query is updated and committed by another user or session after the query has been started. The most common reasons for error ORA-1555 (snapshot too old) are: A long running query due to a poorly qualified data access A high processing time between fetches of the same query Incorrect rollback segment setup A long run query can cause some activities in the ABAP program loop to take too long, even if the SQL statement is correct. For example: SELECT ... Fetch (a long running activity) ENDSELECT Before you try to change the number or size of the rollback segments, check if the problem is caused by expensive queries, such as inefficient application design, wrong index design, or

insufficient cost-based optimizer statistics. You can adjust the rollback segment setup by adding more rollback segments or making them larger. How the error Checkpoint not Complete occurs: 1. An online redo log switch occurs and the check point process tags the online redo log group being written to until the checkpoint triggered by the online redo log switch is complete. 2. A checkpoint is triggered. That means, dirty pages from the data buffer are being written to disk by the database writer (DBWR). 3. Transactions are still occurring and committing, so data is written from the redo log buffer to the online redo logs in parallel to the checkpoint. 4. Eventually, after some log switches, all the online redo logs are in use before the checkpoint triggered has finished. No data can be flushed from the redo log buffer to an online redo log file because all online redo log files are necessary for instance recovery. The Oracle RDBMS automatically handles this situation, no further changes are processed until the checkpoint is complete and the online redo log file can be overwritten. The message Checkpoint not complete is written to the Oracle alert log alert_<SID>.log. This problem generally occurs during high database activity and during peak hours. If the message appears frequently, increase the number of online redo log groups. Increasing the size of the online redo log files is not recommended, unless the time between the two log switches is less than three minutes. Note: This problem should only be of concern if it occurs frequently.

R/3
If data from the database is required to support transaction processing, a request for data is sent to the database interface, which in turn sends a request through the network to retrieve the information from the database. When it receives the request, the database searches its shared memory buffers. If the data is found, it is sent back to the work process. If the data is not found, it is loaded from the disk into the shared memory buffers. After being located, the data is taken from the shared memory buffers and sent back across the network to the requesting database interface. Transaction processing resumes. CPU time is the amount of time during which a particular work process has active control of the central processing unit (CPU).
Workload

time statistics include: Response time in milliseconds: Starts when a user request enters the dispatcher queue; ends when the next screen is returned to the user. The response time does not include the time to transfer from the screen to the front end. Wait time in milliseconds: This is the time a user request sits in the dispatcher queue. It starts when user request is entered in the dispatcher queue; and ends when the request starts being processed.

Roll-in time in milliseconds: The amount of time needed to roll user context information into the work process. Load time in milliseconds: The time needed to load from the database and generate objects like ABAP source code, CUA, and screen information. Processing time : This is equivalent to response time minus the sum of wait time, database request time, load time, roll time, and enqueue time. Database request time : Starts when a database request is put through to the database interface; ends when the database interface has delivered the result. CPU time in milliseconds: This is the CPU time used by the R/3 work process If a problem is detected, the data in the Workload Monitor (Transaction ST03N) can be used as follows to identify the area of the system where the problem is located. First check for general performance problems affecting all transactions. Good general performance is normally indicated by: Wait time < 10% response time Main menu (choose Transaction Profile) < 100 ms In the Workload Monitor, the following values normally indicate good performance: Average roll-in time < 20 ms Average roll wait time < 200 ms Average load (and generation) time < 10 % of response time (<50 ms) Average database request time < 40 % of (response time - wait time) Average CPU time < 40 % of (response time - wait time) Average CPU time Not much less than processing time Average response time - Depends on customer requirements there is no general rule