Database Storage

It is recommended that you use Oracle Automatic Storage Management (ASM) to manage database storage.

ASM

The benefits of using ASM include:
  • Improved I/O performance and scalability
  • Simplified database administration
  • Automatic I/O tuning
  • Reduction in number of objects to manage
For more information, consult these sources:
  • ASM documents available on the Oracle Web site.
  • Storage vendor best practice papers about how to configure ASM for their storage products.

Raw Disks

For performance-critical systems, importing only raw devices into ASM is recommended. For high-volume processing environments, ensure that ASM is configured with disk devices from high-performance disk storage arrays. Some characteristics that you should look for include large NVRAM caches in order to buffer the disk reads and writes, and for efficient RAID implementation.

Configure ASM with External Redundancy to ensure that redundancy is provided by your storage array.

Raw devices (raw partitions or raw volumes) can be used directly under Oracle on UNIX-based or Linux-based systems and can help performance. However, raw disks have the following potential disadvantages:

  • Raw devices may not solve problems with file size writing limits.

    To display current UNIX file size limits, run the following command:

    ulimit -a

  • It may not be possible to move files to other disk drives if you are using raw devices. If a particular disk drive has intense I/O activity, and performance will benefit from the movement of an Oracle data file to another drive, it is likely that no acceptably-sized partition or volume exists on a drive with less I/O activity.
  • Raw devices are more difficult to administer than data files stored on a file system or in an Automatic Storage Management disk group.

When deciding whether to use raw devices, consider the following issues:

  • Raw disk partition availability

    Use raw partitions for Oracle files only if you have at least as many raw disk partitions as Oracle data files. If disk space is a consideration, and the raw disk partitions are already created, match the data file size to the partition size as closely as possible to avoid wasting space.

    You must also consider the performance implications of using all the disk space on a few disks as opposed to using less space on more disks.

  • Logical volume manager

    Logical volume managers manage disk space at a logical level and hide some of the complexity of raw devices. With logical volumes, you can create logical disks based on raw partition availability.

    The logical volume manager controls fixed-disk resources by:
    • Mapping data between logical and physical storage
    • Enabling data to span multiple disks and to be discontiguous, replicated, and dynamically expanded

    For RAC, you can use logical volumes for drives associated with a single system, as well as those that can be shared with more than one system of a cluster. Shared drives enables all the files associated with a RAC database to be placed on these shared logical volumes.

  • Dynamic performance tuning

    To optimize disk performance, you can move files from disk drives with high activity to disk drives with low activity. Most hardware vendors who provide the logical disk facility also provide a graphical user interface (GUI) that you can use for tuning.

    Refer to your operating system documentation on how to use raw devices with your OS.

Tablespaces (Single or Multiple)

Prior to production, you should plan the overall storage strategy. The DDLs to create temporary tablespaces and data tablespaces are left to the discretion of the customer. General recommendations include:
  • Implement these tablespaces as locally managed tablespaces (LMTs) by specifying extent management as local when creating the tablespace.
  • Implement tablespaces with Automatic Space Management by specifying segment space management as auto.
  • With LMTs, you may want to consider creating tablespaces that store small reference tables with the autoallocate extent allocation model.
  • Consider putting large tables into their own tablespace and using the uniform extent allocation model. Use the default extent size 1 MB.
  • Create your temporary tablespace as a temporary data file (temp files). Temp files are used to store intermediate results, such as from large sort operation. Changes to temp files are not recorded in the redo logs.
  • Sterling B2B Integrator does not support splitting a singular application table into different tablespaces or partitions.

I/O Sub-System Response Time

Sterling B2B Integrator is an On-Line Transaction Processing (OLTP) application. As an OLTP application, database response time to the I/O sub-system needs to be in the single digit range even during the peak periods. The database response time to the I/O sub-system should be less than:
  • 5 ms for logs. 1ms or better is recommended.
  • 10 ms or better for data. 5ms is recommended.