Difference between CouchDB and Relational Database

1. CouchDB:

Apache CouchDB is an open-source document-oriented NoSQL database that uses multiple formats and protocols to store, transfer, and process its data, it uses JSON to store data, JavaScript as its query language using MapReduce, and HTTP for an API. It was developed by Apache Software Foundation and initially released in 2005. It is written in Erlang.

2. Relational Database:

RDBMS stands for Relational Database Management Systems. It is most popular database. In it, data is store in the form of row that is in the form of tuple. It contain numbers of table and data can be easily accessed because data is store in the table. This Model was proposed by E.F. Codd.

Difference between CouchDB and Relational Database:

COUCHDB	RELATIONAL DATABASE
It is developed by Apache Software Foundation and initially released in 2005.	It is developed by Oracle on May 1995.
It is written in Erlang language.	It is developed in C and C++ languages.
The primary database model for CouchDB is the Document Store.	The primary database model for a relational database is client/server model.
It can handle only one connection at a time.	It can handle multiple connections simultaneously.
It does support XML data format.	It does not support XML data format.
In CouchDB, there is no predefined datatypes.	It supports predefined data types such as float, date, number, etc.
It does not support Secondary indexes.	It supports secondary indexes.
It does not support ACID transactions.	It provides ACID transactions.
It supports Map Reduce method.	It does not support Map-Reduce method.
It has no Data Schema.	It has Data Schema.

Continue reading

Multimedia Database

Multimedia database is the collection of interrelated multimedia data that includes text, graphics (sketches, drawings), images, animations, video, audio etc and have vast amounts of multisource multimedia data. The framework that manages different types of multimedia data which can be stored, delivered and utilized in different ways is known as multimedia database management system. There are three classes of the multimedia database which includes static media, dynamic media and dimensional media.

Content of Multimedia Database management system :

1. Media data – The actual data representing an object.

2. Media format data – Information such as sampling rate, resolution, encoding scheme etc. about the format of the media data after it goes through the acquisition, processing and encoding phase.

3. Media keyword data – Keywords description relating to the generation of data. It is also known as content descriptive data. Example: date, time and place of recording.

4. Media feature data – Content dependent data such as the distribution of colors, kinds of texture and different shapes present in data.

Types of multimedia applications based on data management characteristic are :

1. Repository applications – A Large amount of multimedia data as well as meta-data(Media format date, Media keyword data, Media feature data) that is stored for retrieval purpose, e.g., Repository of satellite images, engineering drawings, radiology scanned pictures.

2. Presentation applications – They involve delivery of multimedia data subject to temporal constraint. Optimal viewing or listening requires DBMS to deliver data at certain rate offering the quality of service above a certain threshold. Here data is processed as it is delivered. Example: Annotating of video and audio data, real-time editing analysis.

3. Collaborative work using multimedia information – It involves executing a complex task by merging drawings, changing notifications. Example: Intelligent healthcare network.

There are still many challenges to multimedia databases, some of which are :

1. Modelling – Working in this area can improve database versus information retrieval techniques thus, documents constitute a specialized area and deserve special consideration.

2. Design – The conceptual, logical and physical design of multimedia databases has not yet been addressed fully as performance and tuning issues at each level are far more complex as they consist of a variety of formats like JPEG, GIF, PNG, MPEG which is not easy to convert from one form to another.

3. Storage – Storage of multimedia database on any standard disk presents the problem of representation, compression, mapping to device hierarchies, archiving and buffering during input-output operation. In DBMS, a ”BLOB”(Binary Large Object) facility allows untyped bitmaps to be stored and retrieved.

4. Performance – For an application involving video playback or audio-video synchronization, physical limitations dominate. The use of parallel processing may alleviate some problems but such techniques are not yet fully developed. Apart from this multimedia database consume a lot of processing time as well as bandwidth.

5. Queries and retrieval – For multimedia data like images, video, audio accessing data through query opens up many issues like efficient query formulation, query execution and optimization which need to be worked upon.

Areas where multimedia database is applied are :

◉ Documents and record management: Industries and businesses that keep detailed records and variety of documents. Example: Insurance claim record.

◉ Knowledge dissemination: Multimedia database id a very effective tool for knowledge dissemination in terms of providing several resources. Example: Electronic books.

◉ Education and training: Computer-aided learning materials can be designed using multimedia sources which are nowadays very popular sources of learning. Example: Digital libraries.

◉ Marketing, advertising, retailing, entertainment and travel. Example: a virtual tour of cities.

◉ Real-time control and monitoring: Coupled with active database technology, multimedia presentation of information can be very effective means for monitoring and controlling complex tasks Example: Manufacturing operation control.

Continue reading

Oracle Database Clusters

Overview of Clusters

Clusters are an optional method of storing table data. A cluster is a group of tables that share the same data blocks because they share common columns and are often used together. For example, the employees and departments table share the department_id column. When you cluster the employees and departments tables, Oracle physically stores all rows for each department from both the employees and departments tables in the same data blocks.

Figure 1 shows what happens when you cluster the employees and departments tables:

Figure 1 Clustered Table Data

Because clusters store related rows of different tables together in the same data blocks, properly used clusters offers these benefits:

- Disk I/O is reduced for joins of clustered tables.

- Access time improves for joins of clustered tables.

- In a cluster, a cluster key value is the value of the cluster key columns for a particular row. Each cluster key value is stored only once each in the cluster and the cluster index, no matter how many rows of different tables contain the value. Therefore, less storage is required to store related table and index data in a cluster than is necessary in nonclustered table format. For example, in Figure 1, notice how each cluster key (each department_id) is stored just once for many rows that contain the same value in both the employees and departments tables.

Overview of Hash Clusters

Hash clusters group table data in a manner similar to regular index clusters (clusters keyed with an index rather than a hash function). However, a row is stored in a hash cluster based on the result of applying a hash function to the row's cluster key value. All rows with the same key value are stored together on disk.

Hash clusters are a better choice than using an indexed table or index cluster when a table is queried frequently with equality queries (for example, return all rows for department 10). For such queries, the specified cluster key value is hashed. The resulting hash key value points directly to the area on disk that stores the rows.

Hashing is an optional way of storing table data to improve the performance of data retrieval. To use hashing, create a hash cluster and load tables into the cluster. Oracle physically stores the rows of a table in a hash cluster and retrieves them according to the results of a hash function.

Sorted hash clusters allow faster retrieval of data for applications where data is consumed in the order in which it was inserted.

Oracle uses a hash function to generate a distribution of numeric values, called hash values, which are based on specific cluster key values. The key of a hash cluster, like the key of an index cluster, can be a single column or composite key (multiple column key). To find or store a row in a hash cluster, Oracle applies the hash function to the row's cluster key value. The resulting hash value corresponds to a data block in the cluster, which Oracle then reads or writes on behalf of the issued statement.

A hash cluster is an alternative to a nonclustered table with an index or an index cluster. With an indexed table or index cluster, Oracle locates the rows in a table using key values that Oracle stores in a separate index. To find or store a row in an indexed table or cluster, at least two I/Os must be performed:

- One or more I/Os to find or store the key value in the index

- Another I/O to read or write the row in the table or cluster

Continue reading

How to insert an image in to Oracle database using Java program?

To hold an image in Oracle database generally blob type is used. Therefore, make sure that you have a table created with a blob datatype as:

Name Null? Type

----------------------------------------- -------- ----------------------------

NAME VARCHAR2(255)

IMAGE BLOB

To insert an image in to Oracle database, follow the steps given below:

Step 1: Connect to the database

You can connect to a database using the getConnection() method of the DriverManager class

Connect to the Oracle database by passing the Oracle URL which is jdbc:oracle:thin:@localhost:1521/xe (for express edition), username and password as parameters to the getConnection() method.

String oracleUrl = "jdbc:oracle:thin:@localhost:1521/xe";

Connection con = DriverManager.getConnection(oracleUrl, "user_name", "password");

Step 2: Create a Prepared statement

Create a PreparedStatement object using the prepareStatement() method of the Connection interface. To this method pass the insert query (with place holders) as a parameter.

PreparedStatement pstmt = con.prepareStatement("INSERT INTO MyTable VALUES(?, ?)");

Step 3: Set values to the place holders

Set the values to the place holders using the setter methods of the PreparedStatement interface. Chose the methods according to the datatype of the column. For Example if the column is of VARCHAR type use setString() method and if it is of INT type you can use setInt() method.

And if it is of Blob type you can set value to it using the setBinaryStream() or setBlob() methods. To these methods pass an integer variable representing the parameter index and an object of InputStream class as parameters.

pstmt.setString(1, "sample image");

//Inserting Blob type

InputStream in = new FileInputStream("E:\\images\\cat.jpg");

pstmt.setBlob(2, in);

Step 4: Execute the statement

Execute the above created PreparedStatement object using the execute() method of the PreparedStatement interface.

Example

import java.io.FileInputStream;

import java.io.InputStream;

import java.sql.Connection;

import java.sql.DriverManager;

import java.sql.PreparedStatement;

public class InsertImageToOracleDB {

   public static void main(String args[]) throws Exception{

      //Registering the Driver

      DriverManager.registerDriver(new oracle.jdbc.driver.OracleDriver ());

      //Getting the connection

      String oracleUrl = "jdbc:oracle:thin:@localhost:1521/xe";

      Connection con = DriverManager.getConnection(oracleUrl, "system", "password");

      System.out.println("Connected to Oracle database.....");

      PreparedStatement pstmt = con.prepareStatement("INSERT INTO MyTable VALUES(?,?)");

      pstmt.setString(1, "sample image");

      //Inserting Blob type

      InputStream in = new FileInputStream("E:\\images\\cat.jpg");

      pstmt.setBlob(2, in);

      //Executing the statement

      pstmt.execute();

      System.out.println("Record inserted");

   }

}

Output

Connected to Oracle database.....

Record inserted.....

Continue reading

Oracle Database client libraries for Java now on Maven Central

Oracle has published its Oracle Database JDBC client libraries on Maven Central. From now on you can find Oracle Database related jar files under the com.oracle.database group id. You will find all libraries from version 11.2.0.4 (e.g. ojdbc6) to 19.3.0 (e.g. ojdbc10).

Going forward, Oracle will use Maven Central as one of the primary distribution mechanisms for Oracle Database Java client libraries, meaning that you will also be able to find new versions of these libraries on Maven Central in the future.

To get the latest Oracle Database JDBC driver, use the following dependency GAV in your Maven POM file:

<dependency>
  <groupId>com.oracle.database.jdbc</groupId>
  <artifactId>ojdbc10</artifactId>
  <version>19.3.0.0</version>
</dependency>

The com.oracle.database group id has the following subgroups:

◉ oracle.database.jdbc: this group contains all JDBC libraries

     - ojdbc[N].jar:

The Oracle Database JDBC driver compiled with Java [N]

     - ucp.jar:

The Universal Connection Pool for JDBC

    - ojdbc[N]dms.jar:

The Oracle Database JDBC driver compiled with Java [N] including the Dynamic Monitoring System (DMS)

Note: ojdbc8dms.jar and ojdbc10dms.jar contain the instrumentation to support the Dynamic Monitoring System (DMS) and limited support for java.util.logging.

◉ oracle.database.jdbc.debug: this group contains all JDBC debug libraries

◉ oracle.database.security: this group contains all Security libraries for Oracle wallet and more

     - oraclepki.jar:

The Oracle PKI provider used for Oracle wallets

     - osdt_cert.jar:

Certificate management components used for Oracle wallets

     - osdt_core.jar:

Core components between oraclepki.jar and osdt_cert.jar

◉ oracle.database.ha: this group contains all High Availability libraries

     - ons.jar:

Oracle Notification System library

     - simplefan.jar:

Simple Fast Application Notification library

◉ oracle.database.nls: this group contains the Internationalization library

     - orai18n.jar:

orainternationalization.jar --> orai - 18 letters in between - n.jar

◉ oracle.database.xml: this group contains all XML and XML DB related libraries

     - xdb.jar, xdb6.jar

Support for the JDBC 4.x standard java.sql.SQLXML interface

     - xmlparserv2.jar

The Oracle Database XML Parser library, including APIs for:

        - DOM and Simple API for XML (SAX) parsers
        - XML Schema processor
        - Extensible Stylesheet Language Transformation (XSLT) processor
        - XML compression
        - Java API for XML Processing (JAXP)
        - Utility functionality such as XMLSAXSerializer and asynchronous DOM Builder

Note: xdb6.jar is a legacy name, xdb.jar is the new name.

◉ oracle.database.observability: this group contains the Observability library

     - dms.jar:

The Oracle Database Dynamic Monitoring System (DMS)

◉ oracle.database.soda (coming soon!): this group contains the Simple Oracle Document Access driver for Oracle Database

◉ oracle.database.messaging (coming soon!): this group contains the Advanced Queuing Java Messaging Service driver for Oracle Database

With this change, Oracle made it easier than ever before for developers and users alike to consume the Oracle Database Java client libraries.

Continue reading

Persistent Memory Primer

The introduction of Persistent Memory (PMEM) marks the beginning of a revolution in the computing industry. There has always been a separation between system memory where the contents are ephemeral and byte addressable, and storage where the data is persistent and block oriented. Persistent Memory (such as Intel Optane DC Persistent Memory) blurs the line between storage and memory by being both byte addressable as well as persistent.

This new class of Non-Volatile Memory is fast enough to operate alongside conventional (volatile) DRAM in a DIMM (Dual In-Line Memory Module) form factor. Integrating into systems in DIMM slots means that Persistent Memory is able to play a vastly different role than conventional block-oriented storage such as Hard Disk Drives (HDD) or Solid State Disk (SSD).

In this first of a multi-part series on Persistent Memory, we will cover the fundamentals of Persistent Memory and how this technology works under the covers.

3D XPoint Non-Volatile Memory

3D XPoint is the underlying silicon of Intel Optane products and is a new form of non-volatile memory that is different from the Flash-based solutions that have become prevalent in storage products.  NAND Flash or simply Flash is named after the NAND logic gate and is primarily used in memory cards, in USB Flash drives, and in Solid State Drives (SSD) for general purpose storage. 3D XPoint is also available as memory DIMMs as well as in an SSD format branded as Intel Optane SSD.

3D XPoint is faster than NAND Flash, but slower than DRAM. 3D XPoint is also more expensive (by capacity) than Flash but less expensive than DRAM. These 2 factors of cost and speed place 3D XPoint between Flash and DRAM. There is also a set of API and programming standards for Persistent Memory that will support other Non-Volatile (NV) Memory technologies beyond 3D XPoint. Persistent Memory documentation is published at http://pmem.io.

This blog post is focused on Intel Optane DC Persistent Memory, but as previous mentioned, Intel Optane is also available in an SSD form. Optane SSD is faster than NAND Flash SSD and can be used in the conventional manner as storage. 

Speed!

Put plainly, Persistent Memory is fast! It's dramatically faster than spinning disk or Flash SSD, but still a bit slower than volatile memory (DRAM). To put this in perspective, consider the following time measures:

◉ Millisecond = 1/1,000 second

◉ Microsecond = 1/1,000,000 second

◉ Nanosecond = 1/1,000,000,000 second

Data access times (often referred to as latency) for current generation DRAM is in the range of 80-100 nanoseconds, while spinning disk when configured properly should perform in the range of single-digit (1-9) milliseconds. Persistent Memory access times for 64-bytes is around 300 nanoseconds. While this is about 3 times slower than DRAM, it's more than 3,000 times faster than spinning disk.

Performance of Flash SSD falls between these two extremes, and varies based on the configuration and workload. For example, local Flash SSD attached directly to a server will deliver lower latency (faster access) than a server accessing Flash SSD contained in a storage array, although it isn't sharable by multiple servers. Performance also depends on the amount of system load (such as number of users) as well as the type of application (such as OLTP vs. Data Analytics), so performance results will vary.

In a Flash SSD shared storage configuration delivering 200 microsecond I/O latency (0.2 milliseconds), data access is at least 5X faster than spinning disk (assuming 1 millisecond disk access time). However, Persistent Memory data access (64 bytes) at 300 nanoseconds, is more than 600 times faster than Flash SSD (such as an all-flash array).

PMEM vs. Disk Performance

Using traditional disk (HDD) as a baseline, we can clearly see the dramatic performance increases that have come with new technologies, as well as the difference between shared and direct attached storage. The following table shows typical I/O response (or latency) with different technologies. The specific performance on any given system will vary, but this table illustrates the general performance characteristics.

Notice that memory performance is measured in nanoseconds (one billionth of a second), while hard disk drive performance has typically been measured in milliseconds (one thousandth of a second) which is a 10,000X difference in performance.  Notice also that memory is accessed at the byte level, whereas storage (HDD and SSD) is typically accessed in terms of blocks (8K in this example).

Persistent Memory might also be used with a block-oriented application, but it's quite easy to see this doesn't take full advantage of the performance benefits. It's only when the application is specifically designed to work at the byte level that we see the full performance advantages of PMEM. The main challenge in developing applications (such as databases!) to work with PMEM is the granularity of atomicity, which refers to how PMEM persists data as we will see later. Of course the order in which writes occur is also critical to ensuring data integrity. Before we delve into the finer details, it is important to understand the multiple configuration options are that are available.

PMEM Configuration Options

Persistent Memory can be used in multiple configurations, each of which suits a particular need.  The two major configuration options for configuring PMEM are known as "AppDirect Mode" and "Memory Mode", and there are multiple options within AppDirect.

Memory Mode

Persistent Memory can be used in what is known as Memory Mode, where the system uses a combination of PMEM and DRAM and the O/S automatically migrates "hot" blocks to the faster DRAM and "colder" blocks to larger but slower PMEM. The PMEM is essentially used for its larger capacity rather than for purposes of data persistence. Memory Mode operates transparently to the application, and is supported for running Oracle Databases. The majority of this blog is focused on AppDirect, which enables applications to use the Persistent Memory directly rather than simply using it as a larger system memory.

AppDirect Mode

PMEM configured in AppDirect mode begins with a Namespace configuration, which is similar to a logical volume manager for Persistent Memory.  Namespaces are configured on Linux systems using the "ndctl" utility, with 4 options of fsdax, sector, devdax, and raw. File systems can then be mounted on fsdax or sector namespaces. There are 2 layers to understand, which are the Namespace or device configuration, as well as the filesystem layer that is mounted on top of the device.

Namespace Configuration

The ndctl utility is used to configure non-volatile memory devices on the Linux Platform. The command "ndctl list -N" will display a listing of configured namespaces. The following graphic shows fsdax and sector namespaces and their configuration details.

Direct Access (or DAX) refers to the ability to directly access Persistent Memory contents without copying data into buffers in DRAM. The fsdax configuration uses an 8-byte atomicity, whereas sector can use 512 byte or 4,096 byte atomicity. Once the device level is configured, a file system can be mounted on the device.

File System Configuration

On the Linux platform, XFS and ext4 file systems can be mounted for DAX operation on fsdax or sector Namespaces using the -o dax option of the mount command.  There are 3 configuration options for filesystems on top of Namespaces as follows:

◉ fsdax namespace with DAX filesystem (8-byte atomicity)

◉ fsdax namespace with non-DAX filesystem (8-byte atomicity)

◉ sector namespace with non-DAX filesystem (512-byte or 4,096-byte sector atomicity)

The Direct Access (DAX) operation is important for performance, and the application must tolerate the level of atomicity provided by the Persistent Memory device.

8-Byte Atomicity

Persistent Memory (such as Intel Optane DC Persistent Memory) natively operates byte-by-byte rather than in blocks of data like conventional storage. Data is persisted in chunks of 8-bytes at most in Persistent Memory (again, using the default behavior). For applications (like databases) that are based on a BLOCK construct, the 8-byte atomicity of Persistent Memory can be an issue. Writing 8,192 bytes of data (an 8K block) will get persisted in 1,024 chunks of 8-bytes each. Power failure or other abnormal condition can leave blocks of data "fractured" or "torn" into pieces, with portions of the block containing old data and other portions with new data. Applications (such as databases) need to be changed to tolerate this sort of fracturing or tearing of blocks.  Otherwise, these are effectively corrupted blocks of data.

Sector Atomicity

Persistent Memory can be configured for sector level atomicity by defining Namespaces with the "sector" option, which is also known as BTT (Block Translation Table) mode. Tearing of blocks can still occur if the application (i.e. database) block size does not match the block size defined in the Namespace or if there is a misalignment between database block and Persistent Memory sector boundaries. While conventional Disk and Flash SSD devices might have a different block size than the application, there is often a battery-backed controller cache that eliminates the block fracturing problem.

It's interesting to note that applications often use the word "block", conventional disk devices use what are known as "sectors" (sectors of spinning disk), while in an O/S context we often use the word "page" to refer to a unit of storage or memory. These are all 3 terms that essentially refer to the same concept, and they converge when we are talking about Persistent Memory. Blocks of data in an application (or database) map to O/S pages, map to sectors on storage.

In cases with a mismatch of application block size and Namespace sector size, we would still expect some degree of block fracturing (or tearing in the PMEM terminology) because of the lack of controller cache. Ideally, the application (such as a database) should be made tolerant of 8-byte atomicity because it would be very simple to mis-configure the application block size and Namespace sector size or have a misalignment of blocks to sectors that causes tearing or corruption. Data integrity is paramount for a company such as Oracle, so please continue reading this article for more information.

Application Layer: Block-Based Conventional Storage I/O

Persistent storage such as Disk and Flash SSD has always been block-oriented, and applications (such as databases) have been developed to work in this manner. Applications have traditionally been developed to read and write blocks of data in storage. Applications (or system software) handle buffering of data into memory where it is used and manipulated, then saved (or persisted) back to the storage as blocks once the application is done using it as shown in the diagram below.

Applications that are block-oriented (such as databases) will typically use C/C++ read() and write() system calls to access data in block-oriented storage. Block oriented applications expect to read complete blocks from storage and they are designed to write entire blocks to storage. The storage normally guarantees atomicity (success or failure) of writing the entire block, and this is normally backed by a non-volatile cache in the disk controller of modern systems.

Application Layer: Byte-Oriented Applications

Memory is fundamentally byte oriented, and Persistent Memory (such as Intel Optane DC Persistent Memory) is designed to be used by applications in a byte-oriented manner as well.  Applications can access data directly (in-place) with Persistent Memory just like data that has been placed by the application into DRAM.  The C/C++ function mmap() on Linux maps files in Persistent Memory into the application's address space. If the filesystem is mounted using the DAX option (mount -o dax), system buffers are eliminated and the application operates directly on the data residing in Persistent Memory as shown in the following diagram:

Mapping file contents into the application address space and accessing the data directly on Persistent Memory eliminates the copying of data using C/C++ functions such as memcpy(), which eliminates code-path in the processing of data and therefore improves performance. For example, databases will typically copy data into a shared memory segment (like the Oracle SGA) for access by multiple users on a system. Eliminating copying of data obviously has implications for speed of data access, but also related to the handling of atomicity as well shall see later.

DAX: Direct Access to PMEM

The highest level of performance with Persistent Memory comes when an application is designed to work directly against the data without copying it as shown in the diagram below. Accessing 64 bytes of data takes approximately 300 nanoseconds, which is dramatically faster than reading from Solid State Disk (SSD).

Block Oriented Processing

Applications that are designed for block oriented data access will copy data into memory as shown in the diagram below. Users of Persistent Memory should typically see about 6,000 nanosecond access time for 8K of data. While this is much faster than even locally attached Flash SSD, it's not nearly as fast as DRAM or byte-oriented data access on PMEM.

In this diagram, the entire block is being read from PMEM into DRAM, which is functionally the same as Flash SSD or spinning disk from a READ perspective.  However, writing of data brings some big data integrity implications for a block-oriented application.  Of course databases have traditionally been block-oriented, and this certainly applies to the Oracle database.

Implications for Block Oriented Applications

Persistent Memory is fundamentally different from HDD and SSD because of the way data gets written (or persisted).  An application might write a block of data, but this write() operation gets executed in pieces.  Any failure during the write (power failure, system kernel panic, abnormal shutdown, etc.) will result in fracturing or tearing (i.e. corruption) of blocks shown in the following diagram:

A block of data that's partially written will typically mean data corruption for an application that is block-oriented. The application (such as a database) expects the storage to either succeed or fail the ENTIRE write operation rather than leaving it partially completed. This behavior of the storage is called "atomicity" and the granularity of atomicity is critical. Any mismatch in the size of write vs. granularity of atomicity will result in corruption. Conventional disk storage has typically gotten around this issue using a disk cache, which ensures block-level atomicity.

Alert: File Systems and Devices on PMEM

All current versions of the Oracle Database as of this writing are susceptible to corruption in these configurations as outlined in this My Oracle Support Note: File Systems and Devices on Persistent Memory (PMEM) in Database Servers May Cause Database Corruption (Doc ID 2608116.1) viewable here: https://support.oracle.com/epmos/faces/DocumentDisplay?id=2608116.1  The issues underlying this document do not apply to Persistent Memory operating in what is known as Memory Mode or in the SSD form-factor.

An upcoming feature of Oracle Database will take full advantage of the performance benefits of PMEM, as well as addressing the data corruption issues discussed above.  In addition, an upcoming backport of changes into Oracle Database 19c will address the data corruption issues that are the subject of this MOS note. There are no known file systems, device drivers, or other solutions to this data corruption problem.

The Software Engineering Challenge

As we have seen above, the potential performance gains of Persistent Memory are absolutely stunning, with more than 3,000X faster data access, but taking advantage of those performance gains poses some unique software engineering challenges. The primary "reason for being" of databases is data integrity, so solving these challenges is absolutely fundamental for the Oracle Development organization. While it's possible to retrofit Persistent Memory into an existing environment, this approach also includes data integrity issues as we have seen above. At Oracle, we believe the best approach is to design the Oracle Database and Exadata software to fully integrate with Persistent Memory to gain the maximum performance benefits AND to achieve our primary goal of protecting customers data.

Persistent Memory in Exadata X8M

Exadata X8M uses Persistent Memory in the storage tier to accelerate database block I/O, as well as to accelerate commit-related process in the database transaction log. Persistent Memory is used in AppDirect mode in Exadata, and the Exadata software is designed to address the data integrity issues mentioned above by incorporating software logic that is compatible with the 8-byte atomicity of Persistent Memory. Exadata storage also keeps 2 or 3 redundant copies of all data (depending on redundancy configuration) across storage servers for fault tolerance. 

Source: oracle.com

Continue reading