Abstract: JSON Duality Views are object views that return JDV objects. JDV objects are virtual because they are not stored in a database as JSON objects. Rather, JDV objects are stored in shredded form across tables and table attributes (e.g. columns) and returned by a DBMS in response to database commands that request a JDV object from a JSON Duality View. Through JSON Duality Views, changes to the state of a JDV object may be specified at the level of a JDV object. JDV objects are updated in a database using optimistic lock.

Abstract: Techniques for deploying a vector index on multiple nodes of a cluster are provided. In one technique, an instruction is received to create a vector index on a set of vectors that is stored in a vector database that is connected to the multiple nodes. In response, an HNSW index is created based on the set of vectors and the HNSW index is stored on each node. In response to receiving a vector query, a node processes the vector query against its copy of the HNSW index. In another technique, each node retrieves, from a vector database, a respective subset of a set of vectors and generates, based on the respective subset, a respective HNSW index. A vector query is transmitted to each node, which traverses its HNSW index to generate results of the vector query. The results from each node are combined to generate final results.

Abstract: A manager file system (MFS), implemented using an OS process, exposes a path in the native file system as the root of its file system (e.g., mount point). The MFS informs the OS kernel that any file system operation whose path contains the mount point as its prefix, should be handed over to the process by invoking an appropriate interface method that the process implements as part of its file system implementation. The MFS manages one or more applications and leverages the authentication mechanism of the OS to provide fined-grained access control of MFS managed applications.

Abstract: LOB cache swapping is reduced by multi-LOB writing. Under multi-LOB writing, information that tracks changes made by a database transaction to multiple LOBs is retained in a LOB staging buffer after one or more LOB switches. Thus, at commit time, changes to multiple LOBs in a column may be staged in the LOB staging cache, thereby enabling the changes to be made in contiguous data blocks for all the multiple LOBs. Storing LOBs in the same column in this way improves clustering, thereby improving database performance. In addition, LOBs inserted or updated in the same database transaction are often related and accessed together within database transactions and/or query accesses. Clustering the LOB content of such related LOBs allows the LOBs to be accessed more efficiently.

Abstract: JSON Duality Views are object views that return JDV objects. JDV objects are virtual because they are not stored in a database as JSON objects. Rather, JDV objects are stored in shredded form across tables and table attributes (e.g. columns) and returned by a DBMS in response to database commands that request a JDV object from a JSON Duality View. Through JSON Duality Views, changes to the state of a JDV object may be specified at the level of a JDV object. JDV objects are updated in a database using optimistic lock.

Abstract: JSON Duality Views are object views that return JDV objects. JDV objects are virtual because they are not stored in a database as JSON objects. Rather, JDV objects are stored in shredded form across tables and table attributes (e.g. columns) and returned by a DBMS in response to database commands that request a JDV object from a JSON Duality View. Through JSON Duality Views, changes to the state of a JDV object may be specified at the level of a JDV object. JDV objects are updated in a database using optimistic lock.

Abstract: JSON Duality Views are object views that return JDV objects. JDV objects are virtual because they are not stored in a database as JSON objects. Rather, JDV objects are stored in shredded form across tables and table attributes (e.g. columns) and returned by a DBMS in response to database commands that request a JDV object from a JSON Duality View. Through JSON Duality Views, changes to the state of a JDV object may be specified at the level of a JDV object. JDV objects are updated in a database using optimistic lock.

Abstract: A manager file system (MFS) runs as a user space file system. The MFS, implemented using an OS process, exposes a mount point as a communication endpoint to the single process. Mounting, unmounting, and changing configuration of individual database file systems (DBFSs) are done by overloading extended attributes on the mount point. The MFS services all DBFSs mounted at different mount points registered to the single process of the MFS and ensures optimal resource utilization among the DBFSs in the single process while guaranteeing resource isolation.

Abstract: A manager file system (MFS) runs as a user space file system. The MFS, implemented using an OS process, exposes a mount point as a communication endpoint to the single process. Mounting, unmounting, and changing configuration of individual database file systems (DBFSs) are done by overloading extended attributes on the mount point. The MFS services all DBFSs mounted at different mount points registered to the single process of the MFS and ensures optimal resource utilization among the DBFSs in the single process while guaranteeing resource isolation. Multiple MFSs may be created to manage sets of DBFSs.

Abstract: A manager file system (MFS) runs as a user space file system. The MFS, implemented using an OS process, exposes a mount point as a communication endpoint to the single process. Mounting, unmounting, and changing configuration of individual database file systems (DBFSs) are done by overloading extended attributes on the mount point. The MFS services all DBFSs mounted at different mount points registered to the single process of the MFS and ensures optimal resource utilization among the DBFSs in the single process while guaranteeing resource isolation.

Abstract: A manager file system (MFS) runs as a user space file system. The MFS, implemented using an OS process, exposes a mount point as a communication endpoint to the single process. Mounting, unmounting, and changing configuration of individual database file systems (DBFSs) are done by overloading extended attributes on the mount point. The MFS services all DBFSs mounted at different mount points registered to the single process of the MFS and ensures optimal resource utilization among the DBFSs in the single process while guaranteeing resource isolation. Multiple MFSs may be created to manage sets of DBFSs.

Abstract: A manager file system (MFS), implemented using an OS process, exposes a path in the native file system as the root of its file system (e.g., mount point). The MFS informs the OS kernel that any file system operation whose path contains the mount point as its prefix, should be handed over to the process by invoking an appropriate interface method that the process implements as part of its file system implementation. The MFS manages one or more applications and leverages the authentication mechanism of the OS to provide fined-grained access control of MFS managed applications.

Abstract: A computer program product, system, and computer implemented method for automatic, repetitive, and gradual shrink of very large database object structures. The approach disclosed herein generally comprises an iterative best efforts approach to automatically shrink a large database object structure(s). The process may comprise identifying a large object (LOB) structure shrink event and LOB structure or LOB structure segment to be shrunk. And executing a shrink operation on the LOB structure or LOB structure segment without blocking access to other extents in the LOB structure or LOB segment structure. This process allows an extent to be shrunk and deallocated. As a result, the process can operate to continually clean a LOB structure or LOB structure segment to decrease fragmentation within the extents of the LOB structure or LOB segment structure.

Abstract: A DBMS maintains delayed and non-delayed messages within a non-delay shard and a delay shard that function as a pair. The DBMS stages non-delayed messages in enqueue-time order within the non-delay shard, and maintains a non-delay dequeue pointer that moves in physical order of the enqueued non-delay messages. The DBMS stages delayed messages in enqueue-time order within bucket shards of the delay shard. Each bucket shard, of a delay shard, represents a time span of delivery times, and messages are assigned thereto based on message delivery time. The delay dequeue pointer comprises a sub-routine to determine the message with the minimum delivery time within a current bucket shard with a time span that includes the current time. The DBMS delivers the next available message out of the delayed and non-delayed shards by comparing the delivery time of the next available message from each shard and delivering the earliest available message.

Abstract: A method and apparatus for message cache sizing are provided. A plurality of messages from one or more enqueuers are enqueued in a queue comprising at least one shard. Each shard includes one or more subshards. A message cache configured to store a plurality of cached subshards is maintained in memory. The plurality of messages is dequeued from the message cache by one or more dequeuers. An estimated enqueue rate is determined for each shard. An estimated dequeue rate is determined for each dequeuer-shard pair. Estimated restore overhead data is determined over a range of candidate message cache sizes based on the estimated enqueue rate for each shard and the estimated dequeue rate for each dequeuer-shard pair. A preferred message cache size is determined based on the estimated restore overhead data.

Abstract: A DBMS maintains delayed and non-delayed messages within a non-delay shard and a delay shard that function as a pair. The DBMS stages non-delayed messages in enqueue-time order within the non-delay shard, and maintains a non-delay dequeue pointer that moves in physical order of the enqueued non-delay messages. The DBMS stages delayed messages in enqueue-time order within bucket shards of the delay shard. Each bucket shard, of a delay shard, represents a time span of delivery times, and messages are assigned thereto based on message delivery time. The delay dequeue pointer comprises a sub-routine to determine the message with the minimum delivery time within a current bucket shard with a time span that includes the current time. The DBMS delivers the next available message out of the delayed and non-delayed shards by comparing the delivery time of the next available message from each shard and delivering the earliest available message.

Abstract: A method and apparatus for message cache management for message queues is provided. A plurality of messages from a plurality of enqueuers are enqueued in a queue comprising one or more shards, each shard comprising one or more subshards. A message cache is maintained in memory. Enqueuing a message includes enqueuing the message in a current subshard of a particular shard, which includes storing the message in a cached subshard corresponding to the current subshard of the particular shard. For each dequeuer-shard pair, a dequeue rate is determined. Estimated access time data is generated that includes an earliest estimated access time for each of a plurality of subshards based on the dequeuer-shard pair dequeue rates. A set of subshards is determined for storing as cached subshards in the message cache based on the earliest estimated access times for the plurality of subshards.

Abstract: A method and apparatus for message cache sizing are provided. A plurality of messages from one or more enqueuers are enqueued in a queue comprising at least one shard. Each shard includes one or more subshards. A message cache configured to store a plurality of cached subshards is maintained in memory. The plurality of messages is dequeued from the message cache by one or more dequeuers. An estimated enqueue rate is determined for each shard. An estimated dequeue rate is determined for each dequeuer-shard pair. Estimated restore overhead data is determined over a range of candidate message cache sizes based on the estimated enqueue rate for each shard and the estimated dequeue rate for each dequeuer-shard pair. A preferred message cache size is determined based on the estimated restore overhead data.

Abstract: A method and apparatus for message cache management for message queues is provided. A plurality of messages from a plurality of enqueuers are enqueued in a queue comprising one or more shards, each shard comprising one or more subshards. A message cache is maintained in memory. Enqueuing a message includes enqueuing the message in a current subshard of a particular shard, which includes storing the message in a cached subshard corresponding to the current subshard of the particular shard. For each dequeuer-shard pair, a dequeue rate is determined. Estimated access time data is generated that includes an earliest estimated access time for each of a plurality of subshards based on the dequeuer-shard pair dequeue rates. A set of subshards is determined for storing as cached subshards in the message cache based on the earliest estimated access times for the plurality of subshards.

Abstract: A method and apparatus for an in-database sharded queue that supports JMS session ordering is provided. Messages from a plurality of enqueuers are stored in a plurality of shards of a particular queue. For each enqueuer, all messages are stored in only one of the shards. Each shard includes one or more subshards, each subshard having one or more partitions of a queue table maintained by a relational database system. All messages from a first enqueuer are stored in partitions of the queue table that are assigned to a first shard of the plurality of shards. All messages from a second enqueuer are stored in partitions of the queue table that are assigned to a second shard of the plurality of shards. Subscribers of the particular queue are caused to dequeue messages from the plurality of shards.