0551-0553

Previous Table of Contents Next

Page 551

• backup disk using all of the remaining disks and parity information. Depending on the RAID level used, this system will continue to work with one disk failure (RAID-5) or with two disk failures (RAID-6). The greatest problem exists in terms of performance because of the increased read/ writes required to maintain parity in the array. The need to maintain parity can become a bottleneck.

  A brief description of common RAID levels follows :

  • RAID-0: Uses striping, no redundant data, and no parity. No failures are allowed. Redundancy is a problem.
  • RAID-1: Uses mirroring, no striping, and no parity. One failure is allowed. Cost is a problem.
  • RAID-1+0: Uses mirroring and striping, and no parity. This is fast and expensive.
  • RAID-2: Not greatly used due to lack of flexibility and complexity. One failure is allowed.
  • RAID-3: Uses striping with parity and no mirroring. One failure is allowed.
  • RAID-4: Uses striping with parity and no mirroring. One failure is allowed.
  • RAID-5: Uses striping with parity and no mirroring. One failure is allowed.
  • RAID-6: Uses striping with two parity disks and no mirroring. Two failures are allowed.
  • RAID-7: Modified RAID-5.
  • RAID-S: Modified RAID-5.

  RAID uses arrays of inexpensive disks to maximize disk performance and data availability. Although the usage of disk mirroring, striping, and parity are not new, RAID combines these elements to provide improved data storage. Across the various official and vendor_defined RAID levels, these three elements are mixed in an attempt to balance data redundancy versus disk performance. Considering the current disk storage trends, this balancing act seems likely to continue. The DBA should keep in mind that the use of RAID is usually determined by systems personnel and that he or she might be required to operate under a RAID level not optimal for his or her database.

• Semaphores and shared memory are used to control access to shared resources and for interprocess communications between processes. Semaphore and shared memory settings are configured within the operating system. The Oracle Installation and Configuration Guide gives the minimum settings for configuring semaphores and shared memory for an Oracle RDBMS. These settings are the minimum required for running the RDBMS. In practice, they should generally be set higher. The DBA can

Page 552

view the current configuration of these interprocess communications (IPC) settings by issuing the UNIX ipcs(1) command.

• One of the drawbacks of Oracle (or any other RDBMS) is the amount of overhead required from the system on which it runs. One of the areas in which Oracle takes extended overhead is processes. The database itself consists of background processes ”PMON, SMON, LGWR, DBWR, and so on ”plus additional processes for each user who connects to the database. Although this value can be limited at the database level through the PROCESSES parameter in the INIT.ORA parameter file, it is important to make certain that the operating system supports the necessary number of processes. It is also important to note that there are tunable settings in the operating system that limit the maximum number of concurrent processes that a particular user (UID) is allowed to have running on the system (referred to as the maximum processes per user tuneable parameter, or maxuprc). Work with your systems administrator to set the appropriate operating systems parameters to an acceptable level for your environment.
• A particular problem in an Oracle RDBMS is the maximum number of open files that a single process can hold. The number of files is defined at the operating system and RDBMS levels. The RDBMS sets this limit with the MAXDATAFILES parameter of the create database statement. There is also a limit at the operating system level either through quotas or operating system tunable parameters. The DBA must work with the systems administrator to ensure that his or her database needs can be met by the current operating system configuration.
  

  The DBA should always consider network performance when evaluating his or her application environment. There are specific tunable parameters that, if set incorrectly, can cause serious performance problems for the application. Reliable performance statistics should be gathered and maintained so that proper workload determinations can be made. Please keep in mind that if the network environment cannot sufficiently support your user community, no amount of operating system tuning will resolve your performance problems. Also keep in mind that an application will more than likely perform differently when operating in a wide area network (WAN) than in a local area network (LAN). This is because your applications data is traveling greater distances (often called hops)through special equipment (routers) designed to manage the WAN. There is additional network overhead in this environment, so expect to see different performance issues when you compare your WAN and LAN statistics. If you begin to experience poor performance with your applications, consider including your network administrator in your efforts to resolve the performance problems.

CAUTION

It is not advisable to change the operating system priority of the Oracle background processes. If these values are altered , the database might process information less efficiently . If you must modify them, set all the database processes to the same value.

Page 553

Parallel Processing

There are two options available with Oracle that immensely enhance overall database application performance. The two options discussed in this section are the parallel server option and the parallel query option. Both of these options ”although each serves its own purpose ”maximize use of system resources to achieve very much improved database performance, especially on very large queries.

Parallel Server Option

You can use the parallel server option (which can be purchased separately from the Oracle server software) to access common data files on a server from databases on two or more servers. Each server has its own CPU and memory, but share the same disk drives . In turn , databases on these servers share the same set of database files. As a result, many benefits are experienced , ranging from high database availability to increased performance.

Suppose that you had a cluster of two servers, each server housing a database and each database sharing common data files. If database 1 fails for some reason (for example, hardware failure), the users of database 1 can be redirected to database 2. Database 2 may be used as a backup to database 1, and vice versa.

Gains in performance will also be experienced because the processing for each database occurs on each individual server. The two similar databases live on a server with their own memory and CPU; thus, they utilize their own resources. Memory contention and CPU usage are drastically decreased and may be decreased further in the future by adding another server to the cluster. The only things shared are the data files.

Parallel Query Option

The parallel query option is the option of taking advantage of the availability of more than one CPU on a server. By using this option with multiple CPUs, database queries can be divided by Oracle into several smaller queries and assigned to multiple processes. Each process resolves its query and then merges the results into a single result set. This process is know as parallelization , or parallelism. The parallel query option is particularly useful in a data warehousing or decision-support environment, where complicated and summarized queries are run and batch transactions are involved in populating the database.

NOTE

Oracle8 supports the capability of performing INSERT, UPDATE, and DELETE transactions in parallel in addition to the SELECT statement in previous releases. Performing data manipulation in parallel provides the potential for data to be populated in batch, in a fraction of the time compared to that of not using the parallel option.

Previous Table of Contents Next