Abstract: Systems and methods are provided for creating a sandbox for an original tenant at a point in time, the original tenant having original tenant data stored in an immutable storage associated with an original tenant identifier, the original tenant data as of the sandbox creation point in time being a virtual snapshot of the original tenant data accessible by a sandbox tenant, where the sandbox tenant data can be changed without changing the original tenant data, and the original tenant data can be changed without changing the sandbox tenant data. A sandbox tenant is created by associating a sandbox tenant identifier with the virtual snapshot of the original tenant data and with sandbox tenant data created by the sandbox tenant subsequent to the sandbox creation point in time. In some implementations, the original tenant is an original sandbox tenant, and the sandbox tenant is at least one new sandbox tenant.

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

Abstract: Systems and methods are provided for performing a point-in-time restore of data of a first tenant of a multitenanted database system. Metadata can be located to identify an archival version of first data of the first tenant stored in immutable storage of the database system. The archival version includes a most recently committed version of each datum prior to a first point in time. By using the metadata, a restore reference set is mapped into a target database instance of the database system. The mapping can be performed when all existing data for a tenant is to be the archival version, and where versions of data and records committed after the point in time are not available to the target database instance.

Abstract: Systems and methods are provided for creating a sandbox for an original tenant at a point in time, the original tenant having original tenant data stored in an immutable storage associated with an original tenant identifier, the original tenant data as of the sandbox creation point in time being a virtual snapshot of the original tenant data accessible by a sandbox tenant, where the sandbox tenant data can be changed without changing the original tenant data, and the original tenant data can be changed without changing the sandbox tenant data. A sandbox tenant is created by associating a sandbox tenant identifier with the virtual snapshot of the original tenant data and with sandbox tenant data created by the sandbox tenant subsequent to the sandbox creation point in time. In some implementations, the original tenant is an original sandbox tenant, and the sandbox tenant is at least one new sandbox tenant.

Abstract: Systems and methods are provided for performing a point-in-time restore of data of a first tenant of a multitenanted database system. Metadata can be located to identify an archival version of first data of the first tenant stored in immutable storage of the database system. The archival version includes a most recently committed version of each datum prior to a first point in time. By using the metadata, a restore reference set is mapped into a target database instance of the database system. The mapping can be performed when all existing data for a tenant is to be the archival version, and where versions of data and records committed after the point in time are not available to the target database instance.

Abstract: Techniques are disclosed relating to create a configuration for a database system. In some embodiments, program instructions of a change set for an application are received from a source code management (SCM) repository. In response to the receiving, a build process is performed that includes causing compilation of the received program instructions to produce program instructions executable to run the application. The build process also includes provisioning the configuration with a schema by retrieving a first set of metadata defining the schema and issuing corresponding data definition language (DDL) instructions to create the schema in the configuration.

Abstract: Systems and methods provide multi-version concurrency control of database records with uncommitted transactions. The system and methods may include receiving a query regarding a transaction counter number. When a transaction header identifying data is updated with the assigned transaction counter number, the updated transaction header may be used in identifying data as an instance of multiversion concurrency control information by the received query. A key lookup may be performed, and when the key lookup encounters an uncommitted row for a transaction number, a corresponding transaction header identifying data to identify a data array element to determine whether the transaction number is committed, and determining the transaction counter number when the transaction number is committed. The transaction counter number may be stamped on the row version record when it is determined that the row is committed.

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

Abstract: Systems and methods provide multi-version concurrency control of database records with uncommitted transactions. The system and methods may include receiving a query regarding a transaction counter number. When a transaction header identifying data is updated with the assigned transaction counter number, the updated transaction header may be used in identifying data as an instance of multiversion concurrency control information by the received query. A key lookup may be performed, and when the key lookup encounters an uncommitted row for a transaction number, a corresponding transaction header identifying data to identify a data array element to determine whether the transaction number is committed, and determining the transaction counter number when the transaction number is committed. The transaction counter number may be stamped on the row version record when it is determined that the row is committed.

Abstract: Systems and methods are provided for creating a sandbox for an original tenant at a point in time, the original tenant having original tenant data stored in an immutable storage associated with an original tenant identifier, the original tenant data as of the sandbox creation point in time being a virtual snapshot of the original tenant data accessible by a sandbox tenant, where the sandbox tenant data can be changed without changing the original tenant data, and the original tenant data can be changed without changing the sandbox tenant data. A sandbox tenant is created by associating a sandbox tenant identifier with the virtual snapshot of the original tenant data and with sandbox tenant data created by the sandbox tenant subsequent to the sandbox creation point in time. Original tenant data is subsequently created and associated with the original tenant identifier, and is not accessible to the sandbox tenant.

Abstract: Systems and methods are provided for creating a sandbox for an original tenant at a point in time, the original tenant having original tenant data stored in an immutable storage associated with an original tenant identifier, the original tenant data as of the sandbox creation point in time being a virtual snapshot of the original tenant data accessible by a sandbox tenant, where the sandbox tenant data can be changed without changing the original tenant data, and the original tenant data can be changed without changing the sandbox tenant data. A sandbox tenant is created by associating a sandbox tenant identifier with the virtual snapshot of the original tenant data and with sandbox tenant data created by the sandbox tenant subsequent to the sandbox creation point in time. Original tenant data is subsequently created and associated with the original tenant identifier, and is not accessible to the sandbox tenant.

Abstract: Techniques are disclosed relating to fencing out a first one of a plurality of nodes configured to handle requests for data stored in a distributed storage. A database system, in various embodiments, stores a value indicating that the first node is permitted to update a catalog stored at a metadata server. In response to a determination to prevent the first node from updating the catalog and writing to the distributed storage, in various embodiments, the database system updates the value to indicate that the first node is not permitted to update the catalog and instructs the distributed storage to prevent write operations to a particular portion allocated to the first node for writing data.

Abstract: Techniques are disclosed relating to a database system synchronizing a current state of the database system among a plurality of nodes configured to handle requests for data of the database system stored in a distributed storage with one of the plurality of nodes being currently active and the other nodes of the plurality of nodes being currently standby nodes. In various embodiments, the active node receives a request to perform a transaction that includes committing data to the distributed storage. In response to receiving the request, in some embodiments, the active node commits the data to the distributed storage to update the current state of the database system and causes storing of metadata that provides an indication of the commitment in a transaction log stored in the distributed storage.

Abstract: Systems and methods are provided for creating a sandbox for an original tenant at a point in time, the original tenant having original tenant data stored in an immutable storage associated with an original tenant identifier, the original tenant data as of the sandbox creation point in time being a virtual snapshot of the original tenant data accessible by a sandbox tenant, where the sandbox tenant data can be changed without changing the original tenant data, and the original tenant data can be changed without changing the sandbox tenant data. A sandbox tenant is created by associating a sandbox tenant identifier with the virtual snapshot of the original tenant data and with sandbox tenant data created by the sandbox tenant subsequent to the sandbox creation point in time. In some implementations, the original tenant is an original sandbox tenant, and the sandbox tenant is at least one new sandbox tenant.

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

Abstract: System and methods are provided for creating a tenant of a database system, the tenant to have tenant data stored in an immutable storage of the database system associated with a tenant identifier. A request may be received at the database system to create a new tenant. A template tenant metadata of a template tenant may be selected at the database system to create the new tenant based on the received request. A new tenant identifier may be created at the database system based on the selected template tenant metadata. The new tenant may be created by associating the new tenant identifier with a snapshot of at least a portion of the template tenant metadata at a point in time when the template tenant metadata is made accessible to the new tenant. Systems and methods are also provided for removing a tenant of a database system by removing references to a tenant identifier.

Abstract: Systems and methods are provided for performing a point-in-time restore of data of a first tenant of a multitenanted database system. Metadata can be located to identify an archival version of first data of the first tenant stored in immutable storage of the database system. The archival version includes a most recently committed version of each datum prior to a first point in time. By using the metadata, a restore reference set is mapped into a target database instance of the database system. The mapping can be performed when all existing data for a tenant is to be the archival version, and where versions of data and records committed after the point in time are not available to the target database instance.

Abstract: Systems and methods provide multi-version concurrency control of database records with uncommitted transactions. The system and methods may include receiving a query regarding a transaction counter number. When a transaction header identifying data is updated with the assigned transaction counter number, the updated transaction header may be used in identifying data as an instance of multiversion concurrency control information by the received query. A key lookup may be performed, and when the key lookup encounters an uncommitted row for a transaction number, a corresponding transaction header identifying data to identify a data array element to determine whether the transaction number is committed, and determining the transaction counter number when the transaction number is committed. The transaction counter number may be stamped on the row version record when it is determined that the row is committed.

Abstract: Systems and methods are provided for creating a sandbox for an original tenant at a point in time, the original tenant having original tenant data stored in an immutable storage associated with an original tenant identifier, the original tenant data as of the sandbox creation point in time being a virtual snapshot of the original tenant data accessible by a sandbox tenant, where the sandbox tenant data can be changed without changing the original tenant data, and the original tenant data can be changed without changing the sandbox tenant data. A sandbox tenant is created by associating a sandbox tenant identifier with the virtual snapshot of the original tenant data and with sandbox tenant data created by the sandbox tenant subsequent to the sandbox creation point in time. Original tenant data is subsequently created and associated with the original tenant identifier, and is not accessible to the sandbox tenant.