Oracle International Corporation

Wei Ming Hu

Juan R Loaiza

Vinay H Srihari

Yunrui Li

Mark Dilman

Douglas N Surber

Jean De Lavarene

Leonid Novak

Ashok Shivarudraiah

Tong Zhou

Alok Pareek

Vidya Hegde

Ramana Yerneni

Ilya Taranov

Lik Wong

Mahesh Baburao Girkar

J William Lee

Dmitry Mikhailovich Potapov

Saurabh Kumar Verma

Francisco Sanchez

Ilesh Garish

Alexander Hwang

Shen-Ban Meng

Amit Ganesh

Roger J Bamford

James William Stamos

Bipul Sinha

William Bridge

Jia Shi

Vikram Joshi

Arvind Nithrakashyap

Benedicto Elmo Garin, Jr

Saurabh Verma

Steven Wertheimer

Wanli Yang

Sachin Vijaykumar Sonawane

Hongjie Yang

Tudor Bosman

Ramana Yemeni

In accordance with an embodiment, described herein are systems and methods for providing direct access to a sharded database. A shard director provides access by software client applications to database shards. A connection pool (e.g., a Universal Connection Pool, UCP) and database driver (e.g., a Java Database Connectivity, JDBC, component) can be configured to allow a client application to provide a shard key, either during connection checkout or at a later time; recognize shard keys specified by the client application; and enable connection by the client application to a particular shard or chunk. The approach enables efficient re-use of connection resources, and faster access to appropriate shards.

System and method for providing direct access to a sharded database

Techniques are provided for processing a database command in a sharded database. The processing of the database command may include generating or otherwise accessing a shard key expression, and evaluating the shard key expression to identify one or more target shards that contain data used to execute the database command.

Automatic derivation of shard key values and transparent multi-shard transaction and query support

Distributed ledgered data is stored within a distributed persistent storage system comprising multiple persistent storage systems as distributed ledgered participants. In various embodiments, the distributed ledgered data is maintained using the native capabilities of a persistent storage system. The distributed ledgered data is replicated as persistent data objects in a 'ledgered repository of objects' that are replicated at each of the persistent storage systems. Changes at one persistent storage system are recorded within a block in a distributed blockchain that is distributed across each of the other distributed ledgered participants. The other distributed ledgered participants read the changes from the blockchain and apply the changes to the respective replicas at each of the other distributed ledgered participants. Hence, this approach is referred to as blockchain apply. Blockchain apply may be used to replicate the repository objects of various forms of PSSs. In a DBMS, a repository of objects is a table, where each record or row is an object in the repository. In a file system, a repository of objects is a directory, where each directory and file therein is an object in the repository. In a document storage system (DOCS), a repository of objects is a collection of documents, where each document is an object in the repository.

Native persistent store support for blockchains

In accordance with an embodiment, the system enables access to a sharded database using a cache and a shard topology. A shard-aware client application connecting to a sharded database can use a connection pool (e.g., a Universal Connection Pool, UCP), to store or access connections to different shards or chunks of the sharded database within a shared pool. As new connections are created, a shard topology layer can be built at the database driver layer, which learns and caches shard key ranges to locations of shards. The shard topology layer enables subsequent connection requests from a client application to use a fast key path access to the appropriate shard or chunk.

System and method for providing access to a sharded database using a cache and a shard technology

Each of a plurality of Worker processes are allowed to perform any and all of the following tasks involving logged work items: (1) reading a subset of the work items from a log; (2) sequentially ordering work items for corresponding data objects; (3) applying a sequentially ordered set of work items to a corresponding data object; and (4) transmitting a subset of work items to a Worker process running on another database server in a cluster, if necessary. These tasks can be performed concurrently, at will, and as available, by the Worker processes. An improved checkpointing technique eliminates the need for the Worker processes to get to a synchronization point and stop. Instead, a Coordinator process examines the current state of progress of the Worker processes and computes a past point in the sequence of work items at which all work items before that point have been completely processed, and records this point as the checkpoint.

High-performance log-based processing

High performance log-based parallel processing of logs of work items representing operations on data objects

A method and system is provided for measuring, guaranteeing, and reducing replication data lag time between a primary system and one or more standby systems. Each standby system determines the lag time between the generation of a consistent version of data on the primary system and the time that the consistent version is applied on the standby system. Applications can request and be guaranteed to receive data from a standby system that is identical to the state on the primary system at the time of the query, or lag the primary state only by a maximum tolerable amount. A standby system may also publish a service that guarantees a maximum lag time and withdraw the service offer when the actual lag time exceeds the guaranteed lag time. Implications for implementing synchronous and asynchronous replication as well as performance optimizations are also discussed.

Controlling data lag in a replicated computer system

Detecting an operating condition in a multi-server data storage system. One or more of the data storage servers are designated with a status within the cluster. The designating may be performed by at least one of the data storage servers. The status is encoded into log data having records that report changes to the primary data storage performed by the cluster of data storage servers. The log data is transmitted from the primary data storage to the standby data storage system. The standby data storage system determines an operating condition of the cluster of data storage servers based, at least in part, on the status.

Using a standby data storage system to detect the health of a cluster of data storage servers

A method and system for replicating database data is provided. One or more standby database replicas can be used for servicing read-only queries, and the amount of storage required is scalable in the size of the primary database storage. One technique is described for combining physical database replication to multiple physical databases residing within a common storage system that performs de-duplication. Having multiple physical databases allows for many read-only queries to be processed, and the de-duplicating storage system provides scalability in the size of the primary database storage. Another technique uses one or more diskless standby database systems that share a read-only copy of physical standby database files. Notification messages provide consistency between each diskless system's in-memory cache and the state of the shared database files. Use of a transaction sequence number ensures that each database system only accesses versions of data blocks that are consistent with a transaction checkpoint.

Reduced disk space standby

Stored data are transported between different systems having different platforms by converting the format of the stored data into a common format either before or after transmitting the stored data from the source database system to the target database system. The common format may be a format that is universal in that the common format is not machine dependent. The stored data may be kept in the common format at the target database system and never converted to another format. Optionally, the stored data may be converted from the common format to a format associated with the target database system, thereby facilitating backward compatibility. A tool may be provided for performing the conversion.

Cross platform transportable tablespaces

Disclosed are methods, systems, and mediums for improving system utilization and throughput. In some embodiments, application requests received at a primary site are routed to a secondary site for processing when the requests are found to be suitable for processing at the secondary site.

Method and mechanism of improving system utilization and throughput

Techniques are provided for detecting lost writes so that data corruption can be avoided. According to one technique, lost writes are detected by comparing version numbers that are indicated in redo log entries with version numbers that are indicated in corresponding blocks in a standby database. According to one technique, which may be used in conjunction with the above technique, lost writes are detected by logging read operations that occur relative to a primary database, and comparing version numbers that are indicated in read log entries with version numbers that are indicated in corresponding blocks in a standby database. According to one technique, lost writes are detected by comparing, in response to read operations, (a) version numbers that are stored in a persistent in-memory cache with (b) version numbers that are indicated in corresponding blocks that are read from a primary database.

Lost write detection and repair

Growing community of inventors

Palo Alto, CA, United States of America

Wei Ming Hu