Abstract: A consensus protocol-based replication approach is provided. For each change operation performed by a leader server on a copy of the database, the leader server creates a replication log record and returns a result to the client. The leader does not wait for consensus for the change operation from the followers. For a commit, the leader creates a commit log record and waits for consensus. Thus, the leader executes database transactions asynchronously, performs replication of change operations asynchronously, and performs replication of transaction commits synchronously.

Abstract: A consensus protocol-based replication approach is provided. Chunks are grouped into replication units (RUs) to optimize replication efficiency. Chunks may be assigned to RUs based on load and replication throughput. Splitting and merging RUs do not interrupt concurrent user workload or require routing changes. Transactions spanning chunks within an RU do not require distributed transaction processing. Each replication unit has a replication factor (RF), which refers to the number of copies/replicas of the replication unit, and an associated distribution factor (DF), which refers to the number of servers taking over the workload from a failed leader server. RUs may be placed in rings of servers, where the number of servers in a ring is equal to the replication factor, and quiescing the workload can be restricted to a ring of servers instead of the entire database.

Abstract: A lead-sync log record is used to synchronize the replication logs of follower shards to the leader shard. In response to a failure to determine that there is a consensus for a database transaction commit operation after a shard server becomes a new leader, the new leader shard performs a sync operation using the lead-sync log record to synchronize replication logs of the follower shards to the replication log of the new leader. A shard server identifies a first transaction having a first log record but not a post-commit log record in the replication log, defines a recovery window in the replication log starting at the first log record of the identified first transaction and ending at the lead-sync log record, identifies a set of transactions to be recovered, and performs a recovery action on the set of transactions to be recovered.

Abstract: A blockchain object stores multiple user blockchains, each blockchain comprising an ordered set of records in the blockchain object. The records of a user blockchain have the same blockchain key value. Users can create multiple blockchains by establishing respective blockchain key values for the blockchains. Like blocks in a blockchain, the records in a user blockchain are ordered by a sequence of numbers that is specific to the user blockchain; each user blockchain has its own sequence of numbers. Each record in a user blockchain holds a sequence number in a field of the blockchain object. An efficient mechanism maintains and assigns a sequence number to a record when appended to a user blockchain.

Abstract: Techniques are described herein for routing queries to particular nodes of a multi-node database system based on the query. A database table is partitioned into a plurality of affinity groups. Each affinity group is assigned a particular node as the master node of the affinity group. A mapping is sent to a query router indicating the master node for each affinity group of the plurality of affinity groups. The query router determines, for a particular query, a target node to which to send the particular query based on the mapping and the particular query.

Abstract: Integrated circuits (IC) are provided. An IC includes a plurality of macros and a top channel. Each macro includes a macro boundary and a main pattern surrounded by the macro boundary. The top channel includes a plurality of first and second sub-channels. Each first sub-channel is arranged between a first macro and a second macro, and is formed by a plurality of first dummy boundary cells. Each second sub-channel is arranged between two of the second macros, and is formed by a plurality of second dummy boundary cells. The macro boundaries of the first macros are formed by the first dummy boundary cells, and the macro boundaries of the second macros are formed by the second dummy boundary cells. A first gate length of dummy patterns within the first dummy boundary cells is greater than a second gate length of dummy patterns within the second dummy boundary cells.

Abstract: Disclosed are semiconductor devices having an interconnection pattern that includes a plurality of parallel conductors including a first conductor aligned with a first axis and a first dummy pattern aligned with a second axis on a first side of the first axis and offset from the first axis by an axis offset distance LAO in which the first dummy pattern includes N dummy conductors having a first dummy conductor length LDC with the dummy conductors being separated by a dummy conductor-to-dummy conductor spacing EED.

Abstract: Techniques are described herein for an integrated in-front database cache (“IIDC”) providing an in-memory, consistent, and automatically managed cache for primary database data. An IIDC comprises a database server instance that (a) caches data blocks from a source database managed by a second database server instance, and (b) performs recovery on the cached data using redo records for the database data. The IIDC instance implements relational algebra and is configured to run any complexity of query over the cached database data. Any cache miss results in the IIDC instance fetching the needed block(s) from a second database server instance managing the source database that provides the IIDC instance with the latest version of the requested data block(s) that is available to the second instance. Because redo records are used to continuously update the data blocks in an IIDC cache, the IIDC guarantees consistency of query results.

Abstract: In Secure-Asynchronous Signing, when a record is inserted into a collection of records by a user, the user specifies a registered digital certificate to associate with the record. The digital certificate was previously registered by the user. To subsequently sign a record, the user provides a digital signature. The digital signature is validated using data in the record and a public key of the digital certificate that was associated with the row. Invalid digital signatures are detected and rejected regardless of how long afterward the attempt to sign the row occurs after inserting the row.

Abstract: Techniques herein store database blocks (DBBs) in byte-addressable persistent memory (PMEM) and prevent tearing without deadlocking or waiting. In an embodiment, a computer hosts a DBMS. A reader process of the DBMS obtains, without locking and from metadata in PMEM, a first memory address for directly accessing a current version, which is a particular version, of a DBB in PMEM. Concurrently and without locking: a) the reader process reads the particular version of the DBB in PMEM, and b) a writer process of the DBMS replaces, in the metadata in PMEM, the first memory address with a second memory address for directly accessing a new version of the DBB in PMEM. In an embodiment, a computer performs without locking: a) storing, in PMEM, a DBB, b) copying into volatile memory, or reading, an image of the DBB, and c) detecting whether the image of the DBB is torn.

Abstract: Herein are high throughput techniques for incorporating cryptographic blockchains into relational data. In an embodiment, a computer indicates, in a database dictionary in a database, that a relational table is for blockchain storage. The relational table contains application column(s). In response to that indication, the relational table is associated with system column(s) that are unmodifiable by administrators and clients of the database. The system column(s) include a cryptographic hash column. A request to store a particular value in a particular application column is received from a client. In response to receiving the request, a cryptographic hash value is calculated for a new row for the relational table. In the relational table, the computer stores the new row that contains: the particular value in the particular application column, and the cryptographic hash value in the cryptographic hash column.

Abstract: 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.

Abstract: 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.

Abstract: 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.

Abstract: 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.

Abstract: A method and an apparatus for implementing a buffer cache for a persistent file system in a non-volatile memory is provided. A set of data is maintained in one or more extents in a non-volatile random-access memory (NVRAM) of a computing device. At least one buffer header is allocated in a dynamic random-access memory (DRAM) of the computing device. In response to a read request by a first process executing on the computing device to access one or more first data blocks in a first extent of the one or more extents, the first process is granted direct read access of the first extent in the NVRAM. A reference to the first extent in the NVRAM is stored in a first buffer header. The first buffer header is associated with the first process. The first process uses the first buffer header to directly access the one or more first data blocks in the NVRAM.

Abstract: 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.

Abstract: Techniques are provided for creating, organizing, and maintaining a sharded database. A sharded database can be created using user-defined sharding, system-managed sharding, or composite sharding. The sharded database is implemented with relational database techniques. The techniques described can be used to route database requests and process queries in a sharded database.

Abstract: Techniques described herein create a sharding environment from existing independent databases, use the sharding environment to issue cross shard queries, create “on all shards” new objects, and create and “on all shards” new users that will have permission to access the data across all database shards.

Abstract: 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.