7/30/2019 105 Saez

1/4

Setting Up the Database for ProductionSetting Up the Database for Production

OverviewOverview

1996 SAP Technology, Inc. 1051

Chapter 105:Chapter 105: Setting Up the Database for ProductionSetting Up the Database for Production

ContentsContents

OverviewOverview............................................................................................................................................................................................................................................................................................................................................................10511051Checking ParametersChecking Parameters........................................................................................................................................................................................................................................................................................................................10511051

OverviewOverview

Take the following steps in order to set up the database for production:

Add new rollback segments (enlarge the rollback tablespace PSAPROLL)

Balance I/O load

Optimize storage parameters of database objects

Test your Backup/Recovery strategy Change the initial passwords

Adjust the parameters in init.ora

Checking ParametersChecking Parameters

The following parameters for INIT.ORAlocated in :\ORANT\DATABASE (forexample, C:\ORANT\DATABASE\INITDEV.ORA) should be checked:

db_block_buffer: The rule-of-thumb value for this parameter is: 15 - 20% (up to 30% for VLDBs) ofinstalled RAM in DB servers.

Explanation: This value determines the size of the SGA cache for buffering table data!Size in bytes = db_block_buffer * db_block_size. Depends on the hit ratio. I.e., thereshould be at least 9 logical reads for every physical read (based on experience).Normally, the logical reads should be 96% of the total (acc. to SAP).

If enough RAM is still available and the SAP buffers need more space, give preference to them.

shared_pool_size: A guideline value for this parameter is: approx. 10% of installed RAM in DBservers.

Explanation: This value represents the size of the shared pool in bytes. The shared pool containsthe row and library caches. The row cache holds DD information, while parsed SQLstatements are stored in the library cache. There is also a subdivision into sharedand private areas. The shared area holds, for example, generally available SQLstatements, while the private area might hold binding variables (in MTSconfigurations only). The dc_* variables, which were settable under ORACLE 6.x,can now only be globally varied by adjusting the shared_pool_size. After the systemhas stabilized and realistic performance statistics have been collected (which takes at

7/30/2019 105 Saez

2/4

Setting Up the Database for ProductionSetting Up the Database for Production

Checking ParametersChecking Parameters

1052 1996 SAP Technology, Inc.

least one day, depending on the load profile), the ratio of recursive calls to user callsshould be less than 1:5. If not, this value should be gradually increased until it is.The get ratio for the DD cache SQL area should be well over 90%, and the pin ratioshould be at least 96%! Please note: if the free memory value in Table V$SGA is verylarge relative to the variable size, then the value of shared_pool_size should be

reduced somewhat. After doing so, it is essential to monitor the above-mentionedparameters (for a few days!).

db_writers: Minimum (n, 10), where n is the number of disks with Oracle data files.

Explanation: Number of DBWR processes that take care of writing changed DB cache blocks todisk. If this value is greater than one, then there is a master process and one or moreslave processes: the master doles out tasks to its slave writers. In the best-casescenario, all disks would be concurrently written-to! ATTENTION: this value isalways = 1 with: All operating system versions prior to 7.0.16 SUN SOLARISVer.7.1.4 or later, OSF/1 3.2 Version 7.2 or later. See notes in CSP!

open_cursors: 800

Explanation: Number of open cursors that a single-user process may have at the same time (thisdefines the maximum address space of a process).

Please note that SAP applications do not close cursors once they have been opened.They instead try to keep their handles open to avoid diminishing performance. Thisvalue needs to be increased to keep pace with the number of SAP applications usedby a customer (see meaning). Keep in mind, however, that in the SAP system eachapplication server process supplies about 4-5 user processes (depending on theapplication).

row_cache_cursor: Based on trial and error, but always at least 100

Explanation: This value represents the number of recursive cursors stored in the row cache (DataDictionary cache in the shared pool) that is needed to select DD information. Sincein many cases this parameter is set to its default value, it is essential to check it.Experience has shown that it should always be at least 100.

log_buffer: 100 - 300kbytes (often 327,680 bytes, in very large systems even more!)

Explanation: Size of the redo log buffer (in bytes) in the SGA. The redo log buffer caches the

modified blocks before they are written to the redo log file. In a very dynamicsystem, it can be beneficial for this value to be several hundred kilobytes. Generallyspeaking, many commits for minor data changes take place, although much largerchanges with a small number of commits also occur, depending on the applicationprofile.

checkpoint_process: TRUE

7/30/2019 105 Saez

3/4

Setting Up the Database for ProductionSetting Up the Database for Production

Checking ParameterChecking Parameters

1996 SAP Technology, Inc. 1053

Explanation: If the operating system supports this option, then it can be used to enable anadditional background process (CKPT) to support the LGWR process. If the OS doesnot support it, then the system will issue the error message unknown init.ora-parameter when booting. The CKPT process takes care of modifying the file headeretc. In more complex systems, this process is needed to take care of modifying the file

headers while the LGWR is writing the checkpoints. This eases the load on the LGWRsomewhat.

timed_statistics: TRUE

Explanation: If TRUE, one gets the CPU execution times (via the buffer manager). This entails aperformance tradeoff, of course. This overhead can be prevented by setting to FALSE.The SAP system can only capture reliable executive time values while this parameter isTRUE.

Note on ORACLENote on ORACLEdc_*dc_* parameters:parameters:In ORACLE 7, these parameters can now only be indirectly controlled Note on ORACLE dc_*parameters:If the table V$ROW_CACHE (st04, [GOTO] [ACTIVITY] [CURRENT STATISTICS] [DICTIONARY])shows that many dc_*parameters have a USED value of 100%, then the possibilities for influencing thisare limited under ORACLE 7. If you raise the value of shared _pool_size, then you also raise the values ofthese dc_*according to predefined distribution rules (within certain limits, linearly!), but not necessarilywith the desired effect. Moreover, if Table V$SGA tells you that the value of free_memory is very large,then increasing shared_pool_sizeany further may not help much. Sometimes performance can be boostedby reducing the size of the shared pool and assigning the memory thus freed to the SAP buffers (or DBbuffers, although this will visibly worsen the dc_* parameters. Experience has shown, however, that in theSAP system it is not absolutely essential for these values to approach those prescribed by ORACLE.

Unless other problems crop up as well, unfavorable values for the dc_* parameters alone wont requireyou to raise the value of shared_pool_size.

Note on the operating system dependency of some parameters:Note on the operating system dependency of some parameters:

With some parameters, both the permissible value range and the possibilities for setting them can dependon the operating system. The ORACLE manual, Installation and Users Guide, provides invaluable adviceon dealing with cases of this kind.

In order to activate any changes of the above parameters, you should stop and start R/3 andOracle database. Refer to the chapter titled, Stopping and Starting the R/3 System Using SAPService Manager.

7/30/2019 105 Saez

4/4

Setting Up the Database for ProductionSetting Up the Database for Production

Checking ParametersChecking Parameters

1054 1996 SAP Technology, Inc.

For further d etails refer to

R/3 System Administration Made Easy

Installing R/3 Version 3.0E with Oracle on Windows NT (Ch. 5)

Completing and Checking the Central Instance Installation of R/3 with Oracle on Win. NT

R/3 Basis Knowledge Products

DBA Oracle CD Reference Going Live Adjust DB Parameters

Basis Courses

Database Administration ORACLE (BC505)