Salesforce Com, Inc.

Salesforce, Inc.

Thomas Fanghaenel

Terry Chong

Jameison Bear Martin

Nathaniel Wyatt

Patrick James Helland

Rohit Agrawal

Aditya Dharmanand Shetty

Vaibhav Arora

James E Mace

Kaushal Mittal

Subho Sanjay Chatterjee

Diego Ongaro

William Charles Mortimore, Jr

Gary J Baker

Raghavendran Hanumantharau

Simon Y Wong

Mark Wilding

Assaf Ben Gur

Andrew Stewart Tucker

Assaf Ben-Gur

Shao-Yuan Ho

Robert Frankus

Piyush Kumar Jain Mahendra Kumar

Jacob Jonghan Park

Andrew Tucker

Mark Mears

Atul Jha

Stephane Geneix

Christopher Drexelius

Techniques are disclosed that relate to truncating a subrange of records from a database table. A computer system receives a request to truncate the subrange of records. The request specifies a conditional expression that is usable to identify the subrange from other subranges of records of the database table. Before truncating the subrange of records, the computer system determines whether the subrange of records can be truncated from the database table with a single-record subrange truncate operation, regardless of a size of the subrange of records, based on whether the conditional expression satisfies a set of preconditions. Based on determining that the conditional expression satisfies those preconditions, the computer system performs the single-record subrange truncate operation that includes generating a truncate record that causes the subrange of records to be truncated from the database table.

Subrange truncation of records

Techniques are disclosed that pertain to tracing performance information. A computer system receives a request from a second computer system to perform operations pertaining to a database statement of a database transaction that is being executed by the second computer system. The computer system determines that the request is an initial request received by the computer system to perform work of that database statement. Based on the determining, the computer system stores, in association with the database statement, baseline information that is indicative of a baseline state of one or more performance metrics. Subsequent to performing the operations, the computer system receives a request from the second computer system for performance information. The computer system derives the performance information from a difference between the current state of the one or more performance metrics and the baseline state. The computer system sends the performance information to the second computer system.

Execution tracing for node cluster

Techniques for downgrading of database software. Code areas that may affect downgradability may be delineated with code markers. Changes to these sections can be made to prevent a new database version from being built unless a process is taken to indicate that any new features be designated as available, but not yet allowed for N software releases. This provides a downgrade window of N releases that will support functionality currently allowed by the database. In response to receiving a downgrade request to a target older database software version, that request can be permitted if all the database features are available or allowed in the target version. If at least one of the database features is not available in the target version, the downgrade requested is not permitted. If the request is permitted, the downgrade operation is commenced.

Downgrading database software via a downgradability test

Techniques are disclosed relating to truncating a tenant's data from a table. A database node may maintain a multi-tenant table having records for tenants. Maintaining the table may include writing a record for a tenant into an in-memory cache and performing a flush operation to flush the record to a shared storage. The database node may write a truncate record into the in-memory cache that truncates a tenant from the table such that records of the tenant having a timestamp indicating a time before the truncate record cannot be accessed as part of a record query. While the truncate record remains in the in-memory cache, the database node may receive a request to perform a record query for a key of the tenant, make a determination on whether a record was committed for the key after the truncate record was committed, and return a response based on the determination.

Mechanisms for truncating tenant data

Techniques are disclosed relating to index metadata that is usable for accessing multi-level data structures. A computer system may operate a database, including maintaining a set of records having a set of corresponding keys. The computer system may create multi-level data structures that facilitate key range lookups against those records. A given multi-level data structure may store key information indicative of a subset of the corresponding keys. The computer system may create separate index metadata that is usable for accessing the multi-level data structures. The index metadata may specify indications of key information that is stored in the multi-level data structures and locations of the multi-level data structures. The computer system may perform a key range lookup that includes using the index metadata to determine a particular set of the multi-level data structures whose key information corresponds to a key range of the key range lookup.

Index for multi-level data structures

This disclosure provides various techniques that may allow for accessing values stored in a data structure that stores multiple values corresponding to database transactions using a skip list. A key may be used to traverse the skip list to access data associated with the key. The skip list maintains on ordering of multiple keys, each associated with a particular record in the data structure, using indirect links between data records in the data structure that reference buckets included in hash table. Each bucket includes pointers to one or more records in the skip list.

Key-value storage using a skip list

Techniques are disclosed relating to merge operations for multi-level data structures, such as log-structured merge-trees (LSM trees). A computer system may store, in a database, a plurality of files as part of an LSM tree and a plurality of database key structures. A given one of the plurality of database key structures may indicate, for a corresponding one of the plurality of files, a set of key ranges derived from database records that are included in the corresponding file. The computer system may determine, using ones of the plurality of database key structures, a key range overlap that is indicative of an extent of overlap of key ranges from a set of the plurality of files with respect to a particular key range. Based on the determined key range overlap, the computer system may assign a priority level to a merge operation that involves the set of files.

Merges using key range data structures

Techniques are disclosed relating to compressing database keys. A computer system may receive a request to write a database record to a storage medium. The database record may include a database key and a corresponding data value. The computer system may compress the database key by replacing a portion of the database key with particular data that identifies a location of a reference database key and an amount of similarity determined between the database key and the reference database key. The computer system may write the database record to the storage medium. The database record may include the compressed database key and the corresponding data value.

Database key compression

System and methods of the disclosed subject matter provide segregating, at a memory storage coupled to a multitenant database system, first tenant data of a first tenant from at least second tenant data of a second tenant, based on a first tenant identifier. A first encryption key associated with the first tenant may be retrieved from a key cache memory based on the first tenant identifier, to encrypt one or more fragments of the first tenant data. The fragments of the first tenant data may be encrypted based on the retrieved encryption key. Non-encrypted header information may be generated for each of the encrypted fragments of the first tenant data, where the header information may have metadata including the first tenant identifier. The encrypted fragments of the first tenant data and the corresponding non-encrypted header information may be stored in the immutable storage.

Systems and methods of database encryption in a multitenant database management system

Techniques are disclosed relating to probabilistic data structures. A database node may maintaining a probabilistic data structure capable of encoding database keys. The probabilistic data structure may include a plurality of levels that are each capable of storing an indication of a transition between successive characters in a database key. The database node may insert a particular database key into the probabilistic data structure and the particular database key may comprise a series of characters. The inserting may include setting, for each transition between successive characters of the series of characters, an indication in a corresponding level of the plurality of levels that is indicative of that transition. The database node may further maintain lineage information specifying one or more lineages that correspond to the transition.

Three-dimensional probabilistic data structure

Systems and methods are provided for migrating a tenant of a database system from a source database instance to a destination database instance. The systems and methods include quiescing the tenant data of the tenant to be migrated from the source database instance to the destination database instance so that no new data is written to the storage of the database system associated with the tenant identifier at the source database instance, transmitting metadata of the tenant to be migrated from the source database instance to the destination database instance, and modifying, at the destination database instance, the metadata of the tenant so that the destination database instance has information to point to groupings of data in the storage for the destination database to access the tenant data.

Systems and methods of database tenant migration

Techniques are disclosed relating to maintaining a cache usable to locate data stored in a data structure. A computer system, in various embodiments, maintains a data structure having a plurality of levels that store files for a database. The files may include one or more records that each have a key and corresponding data. The computer system may also maintain a cache for the database whose entries store, for a key, an indication of a location of a corresponding record in a file of the data structure. In some embodiments, the computer system receives a request to access a particular record stored in the data structure where the request specifies a key usable to locate the particular record. The computer system may retrieve, from the cache via the key, a particular indication of a location of the particular record and may use the particular indication to access the particular record.

Cache for efficient record lookups in an LSM data structure

Techniques are disclosed relating to building an in-memory multi-level data structure useable to determine presence or absence of key ranges in files consisting of database records. In various embodiments, a computer system operates a database, including maintaining a set of records having a set of corresponding keys that are accessible in key-sorted order and generates a multi-level data structure that facilitates key range lookups against the set of records. The generating may include accessing ones of the set of keys in key-sorted order and determining, for a particular accessed key that includes a set of characters, an intermediate level within the multi-level data structure and a subset of the characters of the particular accessed key for insertion. The computer system may insert, starting at the intermediate level, information that identifies the subset of characters, with the inserting being performed without traversing any levels before the intermediate level.

Building of tries over sorted keys

Techniques are disclosed relating to lock wait tracing. A computer system may operate a database that includes a lockable object. The computer may maintain a lock wait queue that stores an indication of processes waiting to acquire a lock on the lockable object. The computer system may store trace records for those processes that, upon releasing a respective lock on the lockable object when another process is waiting in the lock wait queue, have been in contention for the respective lock for over a threshold amount of time. The computer system may present ones of the trace records that identify a timeline that is usable to determine a set of processes that contributed to a delay in a process acquiring a lock on the lockable object.

Lock wait tracing

Systems, devices, and techniques are disclosed for translation of tenant identifiers. A record may be received. A value of a tenant identifier for the record may be determined from a key for the record or a scan descriptor. The value of the tenant identifier in the key for the record may be replaced with a new value for the tenant identifier. A bitmap stored in a record header of the record may be used to identify columns of the record that stored an encoded value of the tenant identifier. An encoded new value of the tenant identifier may be stored in columns identified by the bitmap stored in the record header that include an attribute indicating that tenant identifier translation is enabled.

Growing community of inventors

Oakland, CA, United States of America

Thomas Fanghaenel