This action might not be possible to undo. Are you sure you want to continue?
- 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.
cooperating processes. On each application server these processes include the dispatcher as well as work processes. R/2 and external application systems.The operating system views the R/3 runtime system as a group of parallel.What are the Processes? . dialog free background processing and spooling. Work processes may be installed for dialog processing. .Dialog work processes should not be loaded down with long-running dialog steps. update (V: for the German “Verbuchung”). background processing (B). update. the dialog step is terminated and the started transaction terminates with an error. lock management (E). 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. If this time is exceeded by more than double. which are designed for these types of long-running actions. The remaining dialog work processes would have to handle many more users. the number of work processes depends on the available resources. 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? . A central R/3 System consists of a single instance providing all the necessary R/3 System services. as these work processes would then not be available to other users. In addition to these work process types (dialog processing (D). This allows the administrator to ensure that users execute long-running actions only in the background work processes. This is the reason for the parameter rdisp/max_wprun_time (default setting: 300 seconds). The gateway server (GW or G) allows communication between R/3. Each instance has its own SAP buffer areas. which sets the maximum time a dialog step is allowed to remain in a dialog work process. What is an Instance? -An instance is an administrative unit that combines R/3 System components providing one or more services. thus considerably increasing response times. You use a common instance profile to set parameters for all the components of an instance. The services provided by an instance are started or stopped together.
update. For transactional RFC. which is installed once in each R/3 System (it is configured in the R/3 System profile files). A central instance is an R/3 instance which contains the message service. but can also run on the same server. DVEBMGS00). Asynchronous RFC call: The calling program runs parallel to and independently of function module processing in the target system. and in the sequence in which they were called. and typically contains all R/3 Services (and is named. The dispatchers for the individual application servers communicate through the message server. enqueue. a command line parameter is sent. A dialogue instance is an R/3 instance consisting of dialogue work processes. They are processed only once in the target system. the target system does not have to be available at thetime of the RFC call. B. or S. and spool services. trigger background requests).The example illustrates how an additional background processing server (a) and dialog server (b) are set up. In addition. for example. which provide specific services.When a SAP GUI process is started on the front end. generally run on separate servers. In the case of an error. trigger update. The services may be D. What are the types of RFC Calls? . The message server provides the application servers with a central message service for internal communication (for example. a message is sent to the calling system that you can analyze using transaction SM58. the target system must also be available at the time of the RFC call. The name of an R/3 instance is composed of letters standing for the relevant services. Only then does the calling program continue processing.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. and an instance number which is unique for each computer. E. In addition. How does a SAP LOGON work? . V. G. A central system is an R/3 System consisting of an RDBMS service and the central instance. message. you can configure the frequency and intervals of individual queries. M. within an LUW. This means that you can use the message server performance database for automatic load distribution (logon load balancing). Transactional RFC call: Several function modules can be grouped into one transaction. request and remove locks. These instances. background. gateway. Programmers are responsible for the processing of the results. which respectively stand for dialogue. Presentation servers can also log on to an application server through the message server. 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 . if needed. 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.
spool.PFL. On a dialog instance. the message server returns the IP address and instance number (2) of a specific dispatcher. If the logon is successful. background. . and it is always started. This does not depend on the profiles. The dispatcher forks and creates child processes: The work processes (dialog. All the work processes except the gateway reader connect to the database. .) are created according to the information in the profiles /usr/sap/<SID>/SYS/profile/<SID>_<instance>_<hostname> and /usr/sap/<SID>/SYS/profile/DEFAULT.When logon load balancing is used.The Computing Center Management System (CCMS) is an integral part of the R/3 Basis. which selects a free dialog work process (4) to compare the logon user data with the user data stored in the database (5. 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>. update. The collector and sender are used to implement the central R/3 System log. collector. If the logon user data does not agree with the stored user data. On a central instance. and the sender. logon load balancing may cause the message server to select another dispatcher for the user to work with. no logon is allowed. The number of dispatchers available for a particular logon is configured in the system. SAPSTART starts the message server. 6). The gateway reader. 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. dispatcher. If a user logs off and then logs on again to the system. only the sender and the dispatcher are started. This dispatcher and its work processes are used for the duration of the session. What is CCMS? . . How does “startsap” work in UNIX? . Logon load balancing is useful if certain user groups are assigned to work on specific servers. The frontend process then connects to the assigned dispatcher (3). . The CCMS also provides graphical monitors and management utilities. The message server returns the IP address of one of the assigned dispatchers. Response times are stored in the collected workload data. CCMS provides 24-hour unattended system management functions from within R/3 through operation modes and instances.Script startsap calls program SAPSTART. for example the dispatcher that has shown the best response time during the last five minutes. the SAP GUI is established with the user (7-10).
You do not have to adjust the transport profile using operating system functions.What are Operation Modes? . A list is displayed showing the parameters set in transport profile. TMS generates and manages this transport profile as a part of the transport domain configuration. customers require more dialog processes during the day and more background processes during the night. TMS generates and manages this transport profile as a part of the transport domain configuration. To check the availability of the transport directory program in an R/3 System. To display the tp parameters of an R/3 System. This transport file is located in the subdirectory bin of the directory /usr/sap/trans. so you do not need to change the instance profiles for your server and you experience no system downtime. Choose R/3 System → Check → Transport tool.Typically. A hierarchical list is displayed that shows the status of the individual checks. Naming convention: TP_<domain name>. in the STMS System Overview double -click on one R/3 system and select tab Transport tool. call transaction STMS . 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 transport control program of all R/3 Systems in the transport domain is checked. Operation mode switching reconfigures your R/3 System dynamically. To check the availability of the transport control program in an R/3 System. 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. To adjust the proportions of the various R/3 work processes to suit different phases of system activity.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. If you have not selected an R/3 System. You do not have to adjust the transport prof ile using operating system functions. use Transaction STMS (System overview).PFL. 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.
The amount of disk space required depends on the amount of development work: estimate 10 MB for each customizer and developer. which serves as the transport domain controller. trace files. Mount this directory using the operating system tools (nfs for UNIX. You will need additional space for client exports. Before you can configure the transport routes. share for NT) for all systems within a system landscape or a transport group. The configuration of the transport routes is managed in the R/3 System. 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 .CFG) data: Exported data olddata: Old exported data (to be archived or deleted) log: Transport logs. 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. For Windows NT. The subdirectories required in the common transport directory include: bin: Configuration files for tp (TP_<DOMAINNAME>. Test files are created in the subdirectories of the transport directory and in the last step of the check removed. the default path is \\$ (SAPTRANSHOST)\sapmnt\trans and you must define the transport host with the alias SAPTRANSHOST on the domain name server. object classes. The R/3 Parameter DIR_TRANS has to point to the path of the transport directory. the default path is /usr/sap/trans. For Unix. and can be distributed to and activated in all other R/3 Systems connected in the transport domain. and statistics actlog: Action logs for all tasks and requests buffer: Transport buffer for the each system.(System Overview) and choose R/3 System → Check → Transport directory.PFL) and TMS (DOMAIN. indicating which transports are to be imported cofiles: Command or change request infrmation files that include information on the transport type. required import steps.
the client is imported from the file system to the target system. .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. As copying is a lengthy process. client-specific Customizing. transport client-dependent as well clientindependent Customizing data between R/3 Systems. At some future time. use background processing. the same. choose Tools → Administration → Administration → Client Admin. Note that SAP delivers the software with standard clients 000 and 001.You can use a remote client copy to. R/3 Repository objects. You may not work in client 000. 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. Begin the client copy. A remote client copy allows you to copy between clients in different R/3 Systems. Assign the source client for Customizing data. you may not logon to the target client during a client copy. → Client Maintenance. such as ABAP programs. application data. so there is no "hard copy" of the client to be copied. Select the data to be copied using a profile. A remote client copy proceeds in the same way as a local copy. Perform the client copy using the menu options found under Tools → Administration → Administration → Client Admin. and user master records. cross-client Customizing objects are copied during a remote client copy. When using the client copy tools. Therefore. As of 4. data is exported to a file at the operating system level. → Client Copy. Log on to the target client as SAP* with the initial password PASS. SAP recommends that you begin R/3 implementation by creating a new client as a copy of client 000. are not transported with the above tools. the data you can select to be copied includes: user master data. A remote client copy is easy to use. and application data. but sends the data through a remote function call (RFC) connection to the target client. data is transferred directly between the source and target client using remote function calls (RFCs) through a network connection. However. A local client copy copies between clients within the same R/3 System. In a client transport. SAP also recommends that you do not work in the source client during a client copy. but may use client 001. To ensure data consistency. 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.6A. Development objects can only be transported using change requests. for example. identical client copy cannot be duplicated at a later date.
exports the client data asynchronously by calling the transport program tp at the operating system level. To perform a client export. this file contains client-specific data RO< number >. an automatic Repository consistency check is performed. you must import these requests into the target client using TMS. choose Tools → Administration → Administration → Client Admin. however. the data is imported from the operating system files into the target client. then client. The client export performed in the source system <S-SID>. After the import process has completed. A client transport consists of two steps. this file contains Cross-client data RX< number >.To be able to transport all data during the client copy. post-import activities are required possible for object generation steps. After completing the import. → Client Transport → Import Editing. Second. use scheduled background processing. From the R/3 initial screen. This export process will generate up to 3 data files at operating system level: RT< number >. During remote client copy. First. this file is for client-specific data <S-SID>KX<number>. a Repository consistency check can be performed by clicking the RFC system check button in Transaction SCC8. Note: The value for the parameter "rdisp/max_wprun_time" should be increased. this file is for cross-client data <S-SID>KT<number>.specific data. This will help your recognize in advance formal problems that may occur during the import of the source data. a client transport is used to copy data between different R/3 Systems. Like a remote client copy. proceed as follows: Log on to the source client. the recommended value is 1800 seconds. a list of the ABAP Dictionary tables definitions missing in the target system is generated. You must import the data in the following order: first cross-client data. this file contains SAPscript texts Depending on the type of data selected through the client transport profile. this file is also for client-specific data The client export change requests are not imported when an Import all takes place. the system uses the name of the table being currently copied to restart the copy process. During client transport. From the R/3 initial screen. the structures of all copied or transported tables in both systems must be identical. As copying is a lengthy process. If inconsistencies are detected. log on to the target client. a client export extracts client data from the source client to files at the operating system level. To display client transport logs.) Begin the client export. the client copy is terminated and an error message is displayed. → Client Transport → Client Export. the client copy command files added to the buffer of the target system are <S-SID>KO<number>. . If copying is unexpectedly terminated. Indicate the target system to which the client will be copied. choose Tools → Administration → Administration → Client Admin. If inconsistencies are detected. use the Transport Organizer. A client transport differs from a remote client copy in that it does not use RFC. Therefore. (The target system must be defined in TMS as part of the transport domain. Select the data to be copied using a profile.
What is a SAPROUTER? .All log files are physically stored in the transport log directory at operating system level.modify the development class in the object directory. In the example shown here. no password. A route string describes the stations of a connection required between two hosts. where <number> is the serial client copy number.<SID> . will be overwritten by the new kernel functions during an R/3 Release upgrade. 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. SAProuter uses a configurable a route permission table to allow or deny connections from other systems. Client copies ignore tables in the local development class $TMP. SAP also recommends downloading the most recent version from any sapserv system. the connection from the customer’s frontend PC computer1 to SAP’s application server APPSERVER is set up in three steps: 1. . The default value is 3299. it is recommended to define the service. 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. 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. To restore the client and allow logon. The syntax for the sub-strings are: /H/ = indicates the host name. intermediate layer developed by SAP. Under Windows NT. If you want to copy these tables. thus destroying your SAProuter configuration. 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. platform-independent. Under Unix. computer1 sets up the connection to customer_saprouter according to the first substring. /S/ = an optional entry used for specifying the service port. and for the target server. you can start SAProuter from the script startsap. The default is “”. and <SID> is the source system ID. Each route string has a sub-string for each SAProuter in between. SAProuter acts as an application level gateway (proxy) and can be implemented independently of an R/3 System directly on a firewall. Log files are named CC<number>. SAP recommends that the route permission table be maintained in /usr/sap/saprouter/saprouttab (UNIX). Deleting a client entry with client maintenance (Transaction SCC4) allows you to temporarily lock the client. The network interface (NI) is a separate. /W/ = indicates the password for the connection. recreate the client entry using client maintenance. specify the location using the option saprouter -r. If you wish to place this table in another directory or under a name other than saprottab. SAProuter enables you to completely control access to your R/3 System(s).SAProuter is a program that serves as an intermediate station between R/3 Systems or programs.
several data packets are sent to the server and then returned by the server. these should be used with caution. enter command niping -t. customer_saprouter uses the route permission table to check whether the connection is allowed. If no route permission table is found. However. R/3 looks for table saprouttab in the working directory of the SAProuter. If the first field displays a D instead of a P. you can use “wildcards” (*). In the example shown here. In steps 3 and 4. it tests the connection directly between host 2 and host 3. Step 2: In Window 2 (host 2). . 3. SAProuter terminates with an error message. specify all deny entries before permits. When checking accesses. To stop all active niping servers and clients.67 do not need a password to communicate with all of the services on target computers with host addresses (IP address) beginning with 123. Step 4: In Window 3. the defaults are used. A route permission table (saprouttab) must be defined for each SAProuter. This command tests the connection with SAProuter. by entering command niping -c -H host2. Source computer. If you leave the service and password blank. the rest of the route permission table is not checked for this computer. start the test program niping to emulate a server by entering command niping -s. sap_saprouter then sets up the connection to the application server APPSERVER. Service. and passwords of a source and destination host. The route permission table contains the host names. Once this is found. Step 3: In Window 3 (host 3). that is. Step 1: In Window 1 ( host 1) start SAProuter by entering command saprouter -r. sap_saprouter checks whether the route from customer_saprouter to the application server is allowed. saprouter -s stops program SAProuter. For service the default is 3299. port numbers. A host name is interpreted as a route through one or more SAProuters to the server if the host name is preceded with /H/.45. search for saprouter in the Online help. access to the specified computer and its services has been denied. This command tests the connection without SAProuter.2. saprouter -r starts program SAProuter. start the test program niping to emulate a client.45. SAProuter looks for the first appearance of a Permit or a Deny for one specific computer. 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). Target computer. and Password When making entries in these fields. The password is also checked. For a complete list of SAProuter commands. restart the test program niping by entering the command niping -c –H /H/host1/H/host2. use a standard text editor. The route permission table contains a maximum of five fields for each possible access: Permit/Deny/Secure. When you configure the route permission table. This sets up the connection between both SAProuters. no password is required. all computers with IP addresses beginning with 123. Each time an access is requested. To create a route permission table. if the field Password is blank. This command starts SAProuter without parameters.
run-time operations. 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. use the option -G. For logging connections. All important actions such as connection start. 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. 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. you can specify a log file when starting your SAProuter.The trace level can be set to 1 to 3 (1 being lowest detail and 3 being the highest). You can specify the trace to another file by setting the -T option. such as startup or shutdown database The database administration tool SAPDBA requires the restricted database administration privileges available in the group oper. The following OS and database users are available for Oracle administration in an R/3 System: UNIX: ora<SID> (no OPS$ user). saprouter -r -G <log file>. and OPS$<SID>adm Windows NT: <SID>adm. SAPDBA only has access to the tables required for performing R/3 database administration in the background. the operating system user <user_name> can connect to the database without authentication. If the user OPS$<user_name> is defined as identified externally at the database level. for example. <SID>adm. The default destination for the trace file is dev_rout in the work dir. To do this. . NT: OPS$SAPService<SID>) with very few privileges. These privileges are assigned during R/3 installation or upgrade.
ora parameter REMOTE_OS_AUTHENT must be set to TRUE. R/3 work processes and their dedicated shadow processes communicate over a network. ARCH archives a completed online redo log file into an offline redo log file in the archive directory.ora: Contains client side default domain information and optional diagnostic parameters used for client tracing and logging listener.ora: log_archive_start = TRUE).ora: Contains a list of service names for all databases that can be accessed in the network sqlnet. the password for user SAPR3 is retrieved and the database session for user OPS$ is terminated. From this table. 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. This allows remote OS authentication for OS users with an OPS$ user on any computer in the network in which the database is accessible.5B. ARCH determines the archive directory from the init<SID>. TCP/IP is used. On NT. the listener must be running.ora parameter log_archive_dest (default: ?/saparch/) and determines the file name from the parameter log_archive_format. As communication protocol. the archiver does not archive the file. To allow R/3 work processes to connect over the network using the OPS$ mechanism. The work process now connects as user SAPR3 with the password from table SAPUSER. . The Oracle utility lsnrctl is used to start and stop the listener and to check the status of Net8 connections. 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. the database becomes "stuck". 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>. In a UNIX environment. Three operating system files are used in a NET8 configuration.User OPS$ is the owner of table SAPUSER. the process tnslsnr is started. the corresponding online redo log file is released to be overwritten with new log information.ora :Only used on a database server machine. If no freespace is available in the archive directory. 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. After a corresponding number of redo log switches. For Net8 to accept connections on the database server. To change the password of user SAPR3. Once the offline redo log file has been successfully created. the init<SID>. the service "OracleTNSListener" is started. Contains Oracle system IDs for which the listener can receive connections. Database changes cannot be committed as long as this archiver stuck situation persists. 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.
The objects located in the tablespaces SYSTEM. and offline redo log files The operating system users <SID>adm and ora<SID> (on the database server. R/3 System users do not have a database system user.sap configures the backup tools brbackup and brarchive. sapcheck . A data file can be associated with only one tablespace. PSAPROLL. 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. and resides in directory dbs (NT: database) The profile init<SID>. The objects located in the other tablespaces belong to the R/3 database user SAPR3. 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. sapreorg. NEXT EXTENT and MAX EXTENT allow you to manage space allocated to a table. and PSAPTEMP belong either to the Oracle database users SYS or SYSTEM. export datasets are written to directory sapreorg The directories saparch.A tablespace in an Oracle database consists of one or more physical data files. you increase the amount of disk space allocated for the corresponding tablespace. When you add another data file to an existing tablespace. 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>. 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. You can increase a tablespace in two ways: Add a data file to a tablespace. operating system block size should be the same as Oracle data block size. and resides in directory dbs (NT: database) The profile init<SID>. such as data files. online redo log files. 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. Increase the size of a data file.ora In a UNIX environment.ora configures the Oracle instance. the following environment variables are set by R/3 configuration tools: . and sapbackup are used by the SAP database tools. For performance reasons. Do not create any objects owned by other users in these tablespaces. Directory and file names are standardized in the R/3 environment.dba configures the SAPDBA tool. Storage parameters such as INITIAL EXTENT. The environment variable ORACLE_HOME points to this directory.
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. 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. you can check the R/3 System log or the following Oracle files: The Oracle alert log file ORACLE_HOME/saptrace/background/alert_<SID>. and the . an online redo log file can only be reused after it has been completely archived to the offline redo log archive directory saparch. run sapdba -check and check the log file in directory sapcheck . snapshot too old Net8 TCP/IP delay ORA-1578. the online redo log files cannot be completely archived. You should also search for related SAP Notes 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. To begin troubleshooting.log. which contains error information in the case of database instance startup failure To check the R/3 System log. If the directory saparch is full. data block corruption ORA-600. create a customer message in SAPNet. which often contains further information. use transaction SM21.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. 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. If you cannot find an applicable SAP Note. When the database is in ARCHIVELOG mode.log file in the home directory of user <SID>adm.
error ORA-1113 is returned. If saparch becomes full.ora to see if parameter log_archive_start = true. The following is an example of the Oracle alert log file alert_<SID>. The system then prompts the user whether SAPDBA should set the end backup automatically.database will enter the archiver stuck state. or is powered down. the database returns error ORA-1149 (missing end backup). sequence # 1337 ORA-00312: online log 11 thread 1:'/oracle/TC1/origlogA/log_g11m1. Check the file init<SID>. If a missing end backup error occurs. This ensures that the Oracle data file headers of the data files belonging to the tablespace in the online backup mode are not updated. the tablespace must be in begin backup mode during the backup. remove the dummy file and run BRARCHIVE immediately. In this situation. Make the size of the dummy file five times the size of the offline redo log file.dbf’ ORA-19502: write error on file "/oracle/TC1/saparch/TC1arch1_1337. because the tablespaces are in online backup mode when you try to open the database. you do not need to restore any data files. or is shutdown by using shutdown abort. Warning: Do not delete or move files from the archive directory saparch. and you cannot perform transactions until the online redo log file has been completely archived to directory saparch. If you back up a tablespace online without RMAN.dbf" When an archiver stuck situation occurs. If a tablespace remains in begin backup mode and the command shutdown immediate is issued in svrmgrl (or command stopsap db is issued).log: Tue May 19 10:25:11 1998 ORA-00255: error archiving log 11 of thread 1. ensure that saparch has enough disk space to hold at least three times the amount of the daily offline redo log files. If a tablespace is in begin backup mode and the command shutdown immediate is issued in SAPDBA. the Oracle error message ORA-255 or ORA-272 is written to the database alert log.dbf’ ORA-00312: online log 11 thread 1: '/oracle/TC1/mirrlogA/log_g11m2. To check which tablespaces are still in begin backup mode. If the database crashes during an online backup. some tablespaces may remain in the begin backup mode. This means that no further changes are possible to the system. If BRARCHIVE is scheduled to run daily. To avoid an archiver stuck situation: Reserve some disk space by creating a “dummy file” in the archive directory saparch. use SAPDBA and choose Partial restore and complete recovery database. you must perform a database recovery. If this occurs. Monitor how full saparch is. To perform the recovery. use SAPDBA and choose DB Check verification → DB System Check. SAPDBA puts every tablespace into end backup mode before the database is shutdown. For ORA-1113.dbf’ ORA-00334: archived log: '/oracle/TC1/saparch/TC1arch1_1337. Check if user ora<SID> has write authorization to saparch. the R/3 Systems hangs. .
Do not change MaxExtents to unlimited for all segments in your database. From the SAPDBA. To change the values of the MaxExtents parameter for tables and indexes. For example: SELECT . check if the problem is caused by expensive queries. 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. but there is not enough contiguous freespace available in the tablespace. To solve this problem. then this object cannot request any more extents. If you extend several tablespaces. This ensures that the data returned by a single query is consistent with respect to the time when the query began. make sure that you place the data files on different disks. the maximum number of extents is actually 2.The missing end backup error does not occur if the backup is performed with RMAN. Therefore. Do not set the MaxExtents to unlimited on rollback segments. choose Tablespace administration → Alter tablespace → Add Data file.645. otherwise there may be problems with the I/O speed of disk access. run sapdba -next. If the number of extents allocated to an object reaches the maximum number specified in the MaxExtents storage parameter. When this maximum value is reached. use the SAPDBA and choose Reorganization → Alter/show table or index storage parameters → Alter/show parameters.. such as inefficient application design. use SAPDBA to extend the tablespace with one extra data file. You must perform a backup after every change in the file structure. Oracle returns error ORA-1653 (for tables) or ORA1654 (for indexes). wrong index design. The error messages are displayed in both the Syslog file and the ABAP short dump. Oracle enforces statement-level read consistency. Usually. 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.483. or . even if the SQL statement is correct. 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..147. Fetch (a long running activity) ENDSELECT Before you try to change the number or size of the rollback segments. If the storage parameter MaxExtents is set to unlimited. 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. If an extent of a given size is required in a tablespace. a query never sees the data changes made by transactions that commit during the course of execution of the query.
This problem generally occurs during high database activity and during peak hours. which in turn sends a request through the network to retrieve the information from the database. dirty pages from the data buffer are being written to disk by the database writer (DBWR). all the online redo logs are in use before the checkpoint triggered has finished. increase the number of online redo log groups. When it receives the request. Note: This problem should only be of concern if it occurs frequently. Eventually. The message “Checkpoint not complete” is written to the Oracle alert log alert_<SID>. Wait time in milliseconds: This is the time a user request sits in the dispatcher queue. CPU time is the amount of time during which a particular work process has active control of the central processing unit (CPU). after some log switches. so data is written from the redo log buffer to the online redo logs in parallel to the checkpoint. If the data is not found. If the data is found. The response time does not include the time to transfer from the screen to the front end. You can adjust the rollback segment setup by adding more rollback segments or making them larger. The Oracle RDBMS automatically handles this situation. 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. 4. no further changes are processed until the checkpoint is complete and the online redo log file can be overwritten. Workload time statistics include: Response time in milliseconds: Starts when a user request enters the dispatcher queue. a request for data is sent to the database interface. the database searches its shared memory buffers. it is sent back to the work process. A checkpoint is triggered. unless the time between the two log switches is less than three minutes. After being located. 2. the data is taken from the shared memory buffers and sent back across the network to the requesting database interface. Increasing the size of the online redo log files is not recommended. it is loaded from the disk into the shared memory buffers. That means. and ends when the request starts being processed. If the message appears frequently. R/3 If data from the database is required to support transaction processing. 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. 3. Transactions are still occurring and committing.insufficient cost-based optimizer statistics. How the error Checkpoint not Complete occurs: 1. .log. Transaction processing resumes. It starts when user request is entered in the dispatcher queue. ends when the next screen is returned to the user.
Load time in milliseconds: The time needed to load from the database and generate objects like ABAP source code.wait time) Average CPU time Not much less than processing time Average response time .Depends on customer requirements – there is no general rule . First check for general performance problems affecting all transactions. Database request time : Starts when a database request is put through to the database interface. 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 . 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. Good general performance is normally indicated by: Wait time < 10% response time Main menu (choose Transaction Profile) < 100 ms In the Workload Monitor.wait time) Average CPU time < 40 % of (response time . and screen information. and enqueue time. CUA. database request time. Processing time : This is equivalent to response time minus the sum of wait time. roll time.Roll-in time in milliseconds: The amount of time needed to roll user context information into the work process. CPU time in milliseconds: This is the CPU time used by the R/3 work process If a problem is detected. load time. ends when the database interface has delivered the result.