Вы находитесь на странице: 1из 4

Setting Up the Database for Production Overview

Chapter 105: Setting Up the Database for Production


Contents
Overview ................................................................ ................................................................................................ ................................................................ ................................................................ .............................................. ..............1051 1051 Checking Parameters ................................................................ ................................................................................................ ................................................................ ............................................................ ............................1051 1051

Overview
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<SID>.ora

Checking Parameters
The following parameters for INIT<SAPSID>.ORAlocated in <drive>:\ORANT\DATABASE (for example, C:\ORANT\DATABASE\INITDEV.ORA ) should be checked: db_block_buffer: Explanation: The rule-of-thumb value for this parameter is: 15 - 20% (up to 30% for VLDBs) of installed RAM in DB servers. 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., there should 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. A guideline value for this parameter is: approx. 10% of installed RAM in DB This value represents the size of the shared pool in bytes. The shared pool contains the row and library caches. The row cache holds DD information, while parsed SQL statements are stored in the library cache. There is also a subdivision into shared and private areas. The shared area holds, for example, generally available SQL statements, while the private area might hold binding variables (in MTS configurations 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 system has stabilized and realistic performance statistics have been collected (which takes at

shared_pool_size: servers. Explanation:

1996 SAP Technology, Inc.

1051

Setting Up the Database for Production Checking Parameters

least one day, depending on the load profile), the ratio of recursive calls to user calls should 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 ratio should be at least 96%! Please note: if the free memory value in Table V$SGA is very large 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-mentioned parameters (for a few days!). db_writers: Explanation: Minimum (n, 10), where n is the number of disks with Oracle data files. Number of DBWR processes that take care of writing changed DB cache blocks to disk. If this value is greater than one, then there is a master process and one or more slave processes: the master doles out tasks to its slave writers. In the best-case scenario, all disks would be concurrently written-to! ATTENTION: this value is always = 1 with: All operating system versions prior to 7.0.16 SUN SOLARIS Ver.7.1.4 or later, OSF/1 3.2 Version 7.2 or later. See notes in CSP! 800 Number of open cursors that a single-user process may have at the same time (this defines 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. This value needs to be increased to keep pace with the number of SAP applications used by a customer (see meaning). Keep in mind, however, that in the SAP system each application server process supplies about 4-5 user processes (depending on the application). row_cache_cursor: Explanation: Based on trial and error, but always at least 100 This value represents the number of recursive cursors stored in the row cache (Data Dictionary cache in the shared pool) that is needed to select DD information. Since in 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. 100 - 300kbytes (often 327,680 bytes, in very large systems even more!) 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 dynamic system, it can be beneficial for this value to be several hundred kilobytes. Generally speaking, many commits for minor data changes take place, although much larger changes with a small number of commits also occur, depending on the application profile.

open_cursors: Explanation:

log_buffer: Explanation:

checkpoint_process: TRUE

1052

1996 SAP Technology, Inc.

Setting Up the Database for Production Checking Parameters

Explanation:

If the operating system supports this option, then it can be used to enable an additional background process (CKPT) to support the LGWR process. If the OS does not support it, then the system will issue the error message unknown init.oraparameter when booting. The CKPT process takes care of modifying the file header etc. 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 LGWR somewhat. TRUE If TRUE, one gets the CPU execution times (via the buffer manager). This entails a performance 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 is TRUE.

timed_statistics: Explanation:

Note on ORACLE dc_* 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 this are limited under ORACLE 7. If you raise the value of shared _pool_size, then you also raise the values of these dc_* according to predefined distribution rules (within certain limits, linearly!), but not necessarily with the desired effect. Moreover, if Table V$SGA tells you that the value of free_memory is very large, then increasing shared_pool_size any further may not help much. Sometimes performance can be boosted by reducing the size of the shared pool and assigning the memory thus freed to the SAP buffers (or DB buffers, although this will visibly worsen the dc_* parameters. Experience has shown, however, that in the SAP 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 require you to raise the value of shared_pool_size.

Note on the operating system dependency of some parameters:


With some parameters, both the permissible value range and the possibilities for setting them can depend on the operating system. The ORACLE manual, Installation and Users Guide, provides invaluable advice on dealing with cases of this kind. In order to activate any changes of the above parameters, you should stop and start R/3 and Oracle database. Refer to the chapter titled, Stopping and Starting the R/3 System Using SAP Service Manager.

1996 SAP Technology, Inc.

1053

Setting Up the Database for Production Checking Parameters

For further details 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 Basis Courses Database Administration ORACLE (BC505) Reference Going Live Adjust DB Parameters

1054

1996 SAP Technology, Inc.

Вам также может понравиться