Oracle International Corporation

Zuoyu Tao

Kothanda Umamageswaran

Jia Shi

Juan R Loaiza

Vijay Sridharan

Alex Tsukerman

Selcuk Aya

David Friedman

Nilesh Choudhury

Justin Matthew Lewis

Wei Zhang

Yunrui Li

Krishnan Meiyyappan

Alexander Tsukerman

Graham Ivey

Boris Erlikhman

Semen Ustimenko

Zheren R Zhang

Scott Martin

Salini Selvaraj Kowsalya

Masakazu Bando

Yiliang Jin

Somayeh Sardashti

Kai Zhang

Zheren Zhang

Techniques are described for providing one or more clients with direct access to cached data blocks within a persistent memory cache on a storage server. In an embodiment, a storage server maintains a persistent memory cache comprising a plurality of cache lines, each of which represent an allocation unit of block-based storage. The storage server maintains an RDMA table that include a plurality of table entries, each of which maps a respective client to one or more cache lines and a remote access key. An RDMA access request to access a particular cache line is received from a storage server client. The storage server identifies access credentials for the client and determines whether the client has permission to perform the RDMA access on the particular cache line. Upon determining that the client has permissions, the cache line is accessed from the persistent memory cache and sent to the storage server client.

PMEM cache RDMA security

Described is an improved approach to implement fast detection of node death. Instead of just relying on multiple heart beats to fail in order to determine whether a node is dead, the present approach performs an on demand validation using RDMA to determine whether the node is reachable, where the approach of using RDMA is significantly faster than the heartbeat approach.

Fast node death detection

Techniques are provided to adjust the behavior of a cache based on a count of cache misses for items recently evicted. In an embodiment, a computer responds to evicting a particular item (PI) from a cache by storing a metadata entry for the PI into memory. In response to a cache miss for the PI, the computer detects whether or not the metadata entry for the PI resides in memory. When the metadata entry for the PI is detected in memory, the computer increments a victim hit counter (VHC) that may be used to calculate how much avoidable thrashing is the cache experiencing, which is how much thrashing would be reduced if the cache were expanded. Either immediately or arbitrarily later, the computer adjusts a policy of the cache based on the VHC's value. For example, the computer may adjust the capacity of the cache based on the VHC.

Detection of avoidable cache thrashing for OLTP and DW workloads

Data blocks are cached in a persistent cache ('NV cache') allocated from as non-volatile RAM ('NVRAM'). The data blocks may be accessed in place in the NV cache of a &#x201c;source&#x201d; computing element by another &#x201c;remote&#x201d; computing element over a network using remote direct memory access (&#x201c;RMDA&#x201d;). In order for a remote computing element to access the data block in NV cache on a source computing element, the remote computing element needs the memory address of the data block within the NV cache. For this purpose, a hash table is stored and maintained in RAM on the source computing element. The hash table identifies the data blocks in the NV cache and specifies a location of the cached data block within the NV cache.

Non-volatile cache access using RDMA

A shared storage architecture persistently stores database files in non-volatile random access memories (NVRAMs) of computing nodes of a multi-node DBMS. The computing nodes of the multi-node DBMS not only collectively store database data on NVRAMs of the computing nodes, but also host database server instances that process queries in parallel, host database sessions and database processes, and together manage access to a database stored on the NVRAMs of the computing nodes. To perform a data block read operation from persistent storage, a data block may be transferred directly over a network between NVRAM of a computing node that persistently stores the data block to a database buffer in non-volatile RAM of another computing node that requests the data block. The transfer is accomplished using remote direct memory access ('RDMA).

Database with NVDIMM as persistent storage

A shared storage architecture persistently stores database files in non-volatile random access memories (NVRAMs) of computing nodes of a multi-node DBMS. The computing nodes of the multi-node DBMS not only collectively store database data on NVRAMs of the computing nodes, but also host database server instances that process queries in parallel, host database sessions and database processes, and together manage access to a database stored on the NVRAMs of the computing nodes. To perform a data block read operation from persistent storage, a data block may be transferred directly over a network between NVRAM of a computing node that persistently stores the data block to a database buffer in non-volatile RAM of another computing node that requests the data block. The transfer is accomplished using remote direct memory access ('RDMA). In addition to techniques for performing a data block read operation to NVRAM, computing nodes perform a data block write operation to data blocks stored in NVRAM of the NVRAM shared storage architecture. The data block write operation is referred to herein as a one-sided write because only one database process needs to participate in the writing of a data block to NVRAM in order to successfully commit the write.

Remote one-sided persistent writes

Techniques herein are for creating a database snapshot by creating a sparse database. A method involves receiving a creation request to create a sparse database. The creation request has an identity of a parent database. The creation request is processed to create a sparse database. The sparse database has the identity of the parent database. The sparse database does not contain data copied from the parent database. A write request to write data into the sparse database is received. The write request is processed by writing the data into the sparse database. The parent database does not receive the data.

Database snapshots

No-loss rapid recovery performs resynchronization efficiently while concurrently allowing availability to mirrored data on the storage device. No-loss rapid recovery has two stages and involves storage devices that have both a non-volatile cache and primary storage and that operate as mirror buddies. The first stage is referred to herein as the buddy-retention stage. During the buddy-retention stage, writes to mirrored data are not performed on the offline mirror buddy but are performed on the online mirror buddy. The mirrored data changed in the online mirrored buddy is retained in the non-volatile cache of the retention buddy. The next stage is referred to herein as the rapid resynchronization stage. In this stage, the changed mirrored data retained by the retention buddy for no-loss rapid recovery is used to resynchronize the offline buddy. The storage device is resynchronized using the changed mirrored data retained in the cache of the mirror buddy.

Rapid recovery from downtime of mirrored storage device

A method and system for fast file initialization is provided. An initialization request to create or extend a file is received. The initialization request comprises or identifies file template metadata. A set of allocation units are allocated, the set of allocation units comprising at least one allocation unit for the file on a primary storage medium without initializing at least a portion of the file on the primary storage medium. The file template metadata is stored in a cache. The cache resides in at least one of volatile memory and persistent flash storage. A second request is received corresponding to a particular allocation unit of the set of allocation units. Particular file template metadata associated with the particular allocation unit is obtained. In response to the second request, at least a portion of a new allocation unit is generated.

Fast data initialization

Dirty data in a storage device is made current through rapid re-silvering, which uses a mirrored and up-to-date version of the dirty data from another storage device to recover the data. Because under rapid re-silvering cache metadata in volatile memory survives the failure of the cache, the cache metadata is used to determine which subset of data from the other storage device needs to be copied to the storage device being re-silvered. During re-silvering, cache metadata is used to determine which I/O requests from clients are requests for data that is not stale.

Growing community of inventors

Belmont, CA, United States of America

Zuoyu Tao