Support for Very Large Databases

Oracle Database offers a rich collection of features and options to reduce I/O, improve performance, increase storage efficiency, perform backup and recovery, and keep very large databases manageable.

Many of the features and optional products mentioned on this page are discussed in more detail in a white paper on storage optimization. This paper also provides examples of customer achievements.

Advanced Compression offers the capability to compress Oracle Data Guard (standby databases) redo data as it is transmitted over the network. This reduces network bandwidth consumption and may reduce the transmission time of redo data in an Oracle Data Guard configuration.

The ability to compress the metadata associated with a Data Pump job was first provided in Oracle Database 10g Release 2. In Oracle Database 11g, this compression capability has been extended so that table data can be compressed on export. Because it is an inline operation, the reduced dump file size means a significant savings in disk space. Also, the compressed dump file sets are automatically decompressed during import without any additional steps by the database administrator.

Index Key Compression is part of Oracle Database Enterprise Edition, so no additional options or licenses are required. Index compression allows compression of key column values in an index or index-organized table, reducing the storage for repeated values. Customer experiences show that up to 75% less disk space (compared to using a non-compressed index) is needed for a compressed index.

Recovery Manager (RMAN) and Data Pump are the two most commonly used tools to back up the data stored inside an Oracle database. RMAN makes a block-by-block backup of the database data, also known as a “physical” backup, which can be used to perform database, tablespace, or block-level recovery. Data Pump is used to perform a “logical” backup by offloading data from one or more tables into a flat file.

Oracle Advanced Compression includes compression technology that can dramatically reduce the storage requirements for backup data. Due to RMAN's tight integration with Oracle Database, RMAN backup data (widely used by SAP customers) is compressed before it is written to disk or tape and doesn't need to be uncompressed before recovery—providing an enormous reduction in storage costs on top of what can be achieved by table and index compression.

SecureFiles delivers high performance for file or unstructured data comparable to that of traditional file systems while retaining the advantages of the Oracle database. Applications can transparently take advantage of industry-standard encryption for added security, and intelligent storage features like compression and deduplication for increased space savings and faster performance.

SecureFiles Compression utilizes industry-standard compression algorithms to further minimize the storage requirements of SecureFiles data. With SecureFiles compression, typical files (such as documents or XML files) experience a reduction of 2x to 3x in size. Using built-in intelligence, SecureFiles Compression automatically avoids compressing data that would not benefit from compression; for instance, a document that was compressed via a third-party tool before being inserted into the database as a SecureFiles file. With three levels of compression available (LOW, MEDIUM and HIGH), users can determine the optimal storage savings and compression CPU overhead for their environment.

Even before applying compression, there are significant advantages to the way data is internally stored in an Oracle database. Oracle’s storage structures focus on efficiency and utilize only the minimum required space for each data type. Numeric data, for instance, is stored with variable length in Oracle, which means that Oracle uses only the minimum required space to store the NUMBER data type. Depending on the table structure, the effects of all implementation differences combined can easily get extended to a point where other DBMSs use 40-50% more disk space than Oracle Database to store an equivalent dataset in a real-world setting.

Oracle Partitioning allows tables, indexes, and index-organized tables to be subdivided into smaller pieces, enabling these database objects to be managed and accessed at a finer level of granularity. Oracle provides a comprehensive range of partitioning schemes to address every business requirement. Since it is entirely transparent in SQL statements, partitioning can be applied to any application, from OLTP (e.g. SAP ERP) to Data Warehousing (e.g. SAP BW).

Table and Index Partitioning is used by default in SAP BW systems that run on Oracle. In SAP ERP (or similar OLTP) databases it can be implemented using either the SAP Partitioning Engine or a service offered by the Oracle Support and Services for SAP team.

• White Paper: Partitioning with Oracle Database 11g Release 2 (PDF)
• White Paper: Optimizing Storage and Protecting Data with Oracle Database 11g (PDF)

OLTP Table Compression allows data to be compressed during all types of data manipulation operations, including conventional DML such as INSERT and UPDATE. It reduces the associated compression overhead of write operations, making it suitable for transactional or OLTP environments as well and extending the benefits of compression to all application workloads. Part of Oracle’s Advanced Compression option, OLTP Table Compression enables you to access compressed data with no measurable performance degradation.

Oracle uses a variable length representation on disk for multi-byte character sets. This implementation strategy is a significant space advantage, compared to other strategies which have to use a fixed two-byte character set for SAP Unicode systems. About 40% of disk space is saved by using the variable length UTF-8 characters set for SAP-enabled Unicode systems compared to the fixed multi-byte representation.

An SAP Unicode Migration requires a complete export and import of the whole database through R3Load. Typically the time for doing an export or import is determined by a few large tables. To reduce this time, it is possible to break the largest tables into smaller portions and have one R3load job work per table portion. In this situation, Oracle's unique RowID Splitting technology avoids any index access and generates RowID ranges so that data can be physically read from disk. Customer experiences show that R3Load exports using RowID ranges are between 10-20 times faster, using less CPU, memory, and IO resources. A Unicode migration using RowID splitting has achieved export and import rates of up to 1 terabyte of data per hour, meaning that even the largest multi-terabyte databases have been migrated in one weekend.

Explore other features of Oracle Database to find out why it is the database of choice for the majority of SAP customers.

• See all features