Oracle International Corporation

Hongjie Yang

Mahesh Baburao Girkar

Juan R Loaiza

Nitin Karkhanis

Steve Lee

Jiangbin Luo

Benedicto Garin

Robert McGuirk

Michael Harvey

Steven McGee

Yunrui Li

James William Stamos

Wei Ming Hu

Sachin Vijaykumar Sonawane

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

Disclosed are methods and apparatuses to provide a redo repeater that allows for no data loss protection without the performance impact to the primary database even when a significant geographical distance separates the primary and standby databases. The Repeater is a lightweight entity that receives redo from the primary database with the purpose of redistributing that redo throughout the primary/standby system configuration. The Repeater able to extend no data loss protection and switchover functionality to terminal standby databases even though the primary database does not need to have a direct connection with those destinations.

Method and system for implementing a redo repeater

Herein are techniques of zero data loss with asynchronously replicated redo logs. In an embodiment, a first server instance (FSI) of a plurality of server instances (PSI) of a primary database (PDB) sends, to a standby database (SDB) during an shutdown of FSI, a first recovery count (RC) and a remainder of an instance redo log (IRL). In response to recovering FSI, a second server instance of PSI increments a recovery counter to a second RC (SRC), publishes SRC to PSI, and sends SRC to SDB. After restarting FSI, FSI makes a change to contents of PDB, and stores, into IRL, a redo entry that defines the change. During failover, a database management system (DBMS) detects whether RCs associated with FSRL and SSRL are unanimous. If unanimous, DBMS fully rolls forward SDB by replaying FSRL and SSRL. Otherwise, DBMS limits replay and indicates that FSRL and SSRL might be inconsistent.

Zero-data-loss with asynchronous redo shipping to a standby database

Growing community of inventors

Foster City, CA, United States of America

Hongjie Yang