Architecture snapshot isolated access in relational database

Abstract

A relational database system is disclosed that supports operation with versioned metadata. The relational database system includes a lock manager, a transaction manager, and a version-aware metadata storage and cache configured to store and manage versions of metadata to determine which of such versions should be visible at any given point in time, and support to create a correct version of metadata. In one aspect, a transaction manager manages a transaction identifier and its associated start time, end time, and / or commit time. Such data supports the determination of transaction visibility at any point in time, thus supporting the determination of metadata version visibility. In one aspect, such metadata versioning supports snapshot isolation enabling metadata transactions.

Description

Background Technology

[0001] Relational database systems (such as Microsoft SQL Server) typically require complete synchronization between read queries and data definition language operations (“DDL”) that modify the schema, because metadata is not versioned. Therefore, all DDL operations need to be fully exclusive-locked (i.e., schema-modification locks denoted as SCH-M) on all schema objects being modified to keep them synchronized with any concurrent read queries that need to access these objects. This requirement imposes certain operational constraints.

[0002] For example, the SCH-M lock required for a DDL operation cannot be granted until all queries dependent on the modified architecture have completed, thus blocking the DDL operation and causing a period of unavailability, which significantly impacts workload performance. Similarly, while a DDL operation waits for an ongoing query to complete, new queries submitted after a SCH-M lock has been requested are also blocked, further extending the window of unavailability.

[0003] Furthermore, DDL operations invalidate any snapshot transactions that attempt to access schema objects after the DDL operation has been committed, because the schema associated with the transaction snapshot no longer exists after the DDL operation is committed and therefore cannot be retrieved. This can cause unexpected failures in workload queries, and such queries must be retried, further impacting workload performance.

[0004] Similarly, the fact that DDL operations must wait for all ongoing queries to complete before acquiring schema modification locks and continuing execution significantly impacts the health of the secondary replica. The secondary replica relies on log replication, and this log replication must wait for extended periods, as it can be blocked by long-running analytic queries (common in secondary replicas). This can lead to a large accumulation of logs on the primary replica, eventually exhausting log space. Furthermore, this large log replication prolongs recovery time and renders the secondary replica unavailable upon restart or during database failover, as all its accumulated logs must be reprocessed. Summary of the Invention

[0005] This summary is provided to present a simplified view of the selection of concepts, which will be described below in detail. This summary is not intended to identify key or essential features of the claimed subject matter, nor is it intended to limit the scope of the claimed subject matter.

[0006] This paper describes a relational database system capable of operating with versioned metadata. The relational database system includes a lock manager, a transaction manager, and a version-aware metadata store and cache. The version-aware metadata store and cache are configured to store and manage versions of metadata to determine which versions should be visible at any given point in time, and to support the creation of the correct version of the metadata. On one hand, the transaction manager manages transaction identifiers and their associated start time, end time, and / or commit time. This data supports determining transaction visibility at any given point in time, and therefore supports determining metadata version visibility. On the other hand, metadata versioning supports snapshot isolation of metadata transactions.

[0007] Further features and advantages, as well as the structure and operation of various examples, are described in detail below with reference to the accompanying drawings. It is important to note that the concepts and techniques are not limited to the specific examples described herein. Such examples are presented herein merely for illustrative purposes. Based on the teachings included herein, additional examples will be readily apparent to those skilled in the art. Attached Figure Description

[0008] The accompanying drawings, which are incorporated herein and form part of the specification, illustrate embodiments of the present application and, in addition to the description, serve to explain the principles of the embodiments and enable those skilled in the art to make and use the embodiments.

[0009] Figure 1 An example relational database system that provides versioned metadata according to an example embodiment is described.

[0010] Figure 2 An example logical employee table, stored in an example SQL database according to an example embodiment, is depicted.

[0011] Figure 3 An example logical timeline of concurrent data reads and metadata modification transactions using snapshot isolation, according to an example embodiment, is depicted.

[0012] Figure 4 An example logical timeline is depicted based on an example embodiment, illustrating concurrent data reads and metadata modification transactions using committed read snapshot isolation.

[0013] Figure 5A A flowchart is depicted illustrating an example method for operating a relational database system to modify metadata objects when not blocked by concurrent read access to the metadata objects, according to an example embodiment.

[0014] Figure 5B The embodiments of the above are described. Figure 5A The detailed flowchart of the method described in the document.

[0015] Figure 5C The embodiments of the above are described. Figure 5A as well as Figure 5B The detailed flowchart of the method described in the document.

[0016] Figure 6 The description illustrates, according to an embodiment, the recompilation of a query plan for triggering recompilation in snapshot isolation mode. Figure 5A , Figure 5B as well as Figure 5C The detailed flowchart of the method described in the document.

[0017] Figure 7 This is a block diagram of an example computer system in which embodiments can be implemented.

[0018] The features and advantages of the embodiments will become more apparent from the following detailed description taken in conjunction with the accompanying drawings, in which the same reference numerals identify corresponding elements throughout. In the drawings, the same reference numerals generally indicate the same, functionally similar, and / or structurally similar elements. The first appearance of an element in the drawings is indicated by the leftmost numeral(s) of the corresponding reference numeral(s). Detailed Implementation I. Introduction

[0019] Several exemplary embodiments are disclosed in detail below. The scope of this patent application is not limited to the embodiments disclosed herein, but includes combinations of embodiments of this disclosure and modifications thereof. It is worth noting that no section / subsection heading provided herein is intended to be limiting. Embodiments are described herein, and embodiments of any type may be included in any section / subsection. Furthermore, embodiments disclosed in any section / subsection may be combined in any manner with any other embodiments described in the same section / subsection and / or different sections / subsections. II. Example Implementation

[0020] This document describes embodiments within the context of relational database systems that provide versioned metadata. For example, Microsoft® SQL Server and similar relational database systems have historically operated as “single-master” database applications, lacking metadata versioning and requiring metadata modifications to be performed by a single process with full and exclusive access to the modified metadata object. These limitations lead to severe scalability issues because achieving ACID (atomicity, consistency, isolation, and durability) compliance for transactions comes at the cost of concurrency. On the other hand, the embodiments disclosed herein overcome these “single-master” metadata problems by providing native metadata versioning and novel locking schemes to relational database systems, enabling modifications to metadata objects to be performed concurrently with read operations that reference or depend on such metadata objects. In addition to providing native metadata versioning and new locking schemes, the disclosed embodiments of relational database systems using versioned metadata, as further described below, implement snapshot isolation of data definition language (“DDL”) operations that modify metadata objects (e.g., database schemas).

[0021] For example, consider Figure 2 This describes an example logical employee table 202, which can be stored in an example SQL database according to an example embodiment. Table 202 includes rows and columns. Each row corresponds to a specific employee, and each column corresponds to information about each corresponding employee. Each row can be considered a record, and each corresponding column entry for a record can be considered a data field of the corresponding record. For example, the first column labeled emp_id includes the employee ID for each employee. Similarly, other columns include data such as name, title, etc. Each table has a corresponding metadata object stored in the database. As the name suggests, a metadata object includes data about the data. Specifically, it is the data about the data stored in the table corresponding to the object. Therefore, for example, the metadata corresponding to table 202 identifies each column and specifies its data type. When, for example, a DDL command causes a column to be added to or deleted from the table, the metadata object corresponding to that table must also be modified to reflect the new logical structure of the table.

[0022] Snapshot isolation of metadata transactions allows relational database systems with versioned metadata to maintain nearly the same baseline performance as those without versioned metadata. Furthermore, overall system performance is significantly improved by reducing blocking typically caused by DDL operations (architectural changes), which often trigger a large number of read operations.

[0023] The following provides a general description of the example operating environments, followed by a detailed description of these example operating environments and other example embodiments.

[0024] Traditional relational database systems require fully exclusive locks to execute metadata modification commands, such as DDL statements. As a result, snapshot transactions (e.g., read queries) attempting to access metadata objects after a DDL transaction has been committed will fail because the original schema based on the transaction snapshot can no longer be retrieved. On the other hand, this implementation enables such read transactions to succeed by referencing a version of the metadata that existed before the DDL transaction was committed.

[0025] Specifically, the implementation supports concurrent access to metadata objects while allowing modification of these objects through multiple versions. Each schema modification of an object (e.g., via DDL commands) creates a new version of the object, and other accessors can still access the version of the object corresponding to a snapshot of its transaction. For multiple common DDL operations, common DDL operations and other accesses are not blocked while all these operations are in progress (i.e., full read access to the data is provided during such operations). Similarly, continuous redo is not blocked by long-running analytical queries, thus allowing the logs on the master server to be cleaned up before they become too large, and reducing recovery time due to the smaller redo logs.

[0026] The implementation includes reconfiguring the metadata layer to support multi-version control. This is similar to how Multi-Version Concurrency Control (MVCC) applies to data, but in this case, it's implemented for metadata. The contents of system tables and the metadata cache are versioned, enabling versioned access to follow snapshot isolation semantics. In the example, the introduced algorithm supports:

[0027] 1) Query metadata objects based on different attributes (e.g., identifier (ID), name, etc.) and find the most relevant version of the object, even if the attributes of these attributes have changed over time (e.g., when the table is renamed).

[0028] 2) Reload the cache by finding all possible visible versions of the record in the corresponding system table to ensure that all necessary versions of the object are loaded correctly.

[0029] 3) Use the corresponding transaction or statement snapshot information and follow the semantics of snapshot isolation or RCSI (Read Committed Snapshot Isolation) (snapshot isolation mode) to perform versioned access to the cache and underlying system tables.

[0030] 4) Reconfigure the creation and usage of snapshots in the system to ensure that query compilation (which accesses metadata) can perform versioned access to load the correct version of objects without blocking any ongoing DDL. This algorithm also enables internal retries, minimizing failures by not exposing potential failures due to architectural inconsistencies to the user.

[0031] 5) We reconfigure the SQL locking semantics regarding metadata access by introducing two new lock types. These lock types allow us to control which DDL operations and accesses (e.g., depending on the isolation level) should support concurrency. In addition to allowing concurrent access between DDL and queries, our design also supports versioned access to schema information for temporal (AS OF) queries. This enables users to access their tables at the same time they have them.

[0032] The embodiments offer advantages over conventional techniques. For example, the embodiments offer advantages over the following conventional techniques:

[0033] 1) Semi-structured data storage (such as document storage) enables flexible architectures: these systems do not face similar challenges because their loose architectural constraints allow different rows / documents to have different architectures. Despite this advantage, keeping applications and data consistent in such systems is quite challenging for developers, as the architecture can easily diverge over time. The embodiments disclosed in this document support concurrent DDL and queries while still maintaining strict architectural constraints.

[0034] 2) Supports similar functionalities of RDBMS (Relational Database Management Systems). A key difference is that such traditional systems are designed from scratch to support versioned metadata. The embodiments disclosed herein support versioning existing, non-versioned RDBMSs.

[0035] These, along with other features, configurations, and advantages, are described below. Figure 1 describe. Figure 1 An example relational database system 100 that provides versioned metadata is described. For example... Figure 1 As shown, the relational database system 100 includes an execution environment 108, a client 104, and a client 106. The execution environment 108 includes a binder / algebraizer / query optimizer 112, a parser 110, a lock manager 124, a metadata storage device 114, a data storage engine 118, a query execution engine 120, and a transaction manager 122. The metadata storage device 114 includes a metadata cache 116. Based on the following... Figure 1The discussion of the relational database system 100 shown will make other structures and operational embodiments readily apparent to those skilled in the art.

[0036] In an embodiment, Figure 1 The interconnections between each of the depicted clients 104, 106, and execution environment 108 can represent network interconnections. For example, such network connections can be via the Internet. However, portions of the depicted connections can utilize other networks, such as local area networks (LANs), wide area networks (WANs), corporate networks, and may include one or more wired and / or wireless components. Furthermore, Figure 1 The depicted interconnections may represent direct connections between some or all of the various components. In other embodiments, some or all of the depicted components may be incorporated into a single system, thereby the depicted interconnections are logical rather than physical. For example, some or all of the transaction manager 122, data storage engine 118, query execution engine 120, etc., may be incorporated together or separately into the same component as independent logical operation units, wherein the depicted interconnections include data flows between operation units, but are located within the same physical component.

[0037] In various embodiments, clients 104 and 106 can be any number, type, or combination of computing devices or computing systems, including terminals, personal computers, laptops, tablets, smartphones, personal digital assistants, servers(s), game consoles, etc., including internal / external storage devices, for performing the functions / operations described herein to perform operations on relational database system 100, such as providing queries to an SQL server, and performing client-side functions / operations in a client-server scenario. In various embodiments, clients 104 and 106 also include additional components (not shown for brevity and ease of explanation), including (but not limited to) components and subcomponents of other devices and / or systems described herein.

[0038] Clients 104 and 106 may be computing devices associated with a domain, as used herein. A domain typically refers to a physical and / or logical system boundary controlled by an entity within which applications and / or services are hosted, provided, managed, and / or otherwise implemented, and in embodiments, may include subdomains, etc. Exemplary, non-limiting domains include (but are not limited to) network domains, leases of hosted cloud platforms, cloud service providers, enterprise systems, and / or any other type of network or system. A tenant is a specific type of domain that represents an organization within a cloud platform. A tenant's domain within a cloud platform is its lease, where the tenant registers and manages applications, stores data / files, accesses services, etc.

[0039] In various embodiments, the data storage engine 118 and the metadata storage device 114 may include any type and / or number of data storage devices or systems, and may include internal and / or external storage. That is, for example, the metadata storage device 114 may include a monolithic storage device / system, a cloud-based storage system, a distributed storage system, etc.

[0040] Furthermore, despite Figure 1 Each of the client 104, client 106, metadata storage device 114, lock manager 124, data storage engine 118, query execution engine 120, and transaction manager 122 is depicted as a whole component; however, it should be understood that such components can be embodied as any number of computing devices (including servers), and may include any type and number of other resources, including resources that facilitate communication with computing devices connected via one of the aforementioned networks and communication between these computing devices. In embodiments, the servers implementing these components can be organized in any manner, including being grouped into server racks (e.g., 8 to 40 servers per rack, referred to as nodes or "blade servers"), server clusters (e.g., 2 to 64 servers, 4 to 8 racks, etc.), or data centers (e.g., thousands of servers, hundreds of racks, dozens of clusters, etc.). In embodiments, the servers may be located in the same location (e.g., within one or more nearby buildings with associated components such as backup power, redundant data communication systems, environmental control devices, etc.) to form a data center, or may be arranged in other ways. Therefore, in the embodiments, client 104, client 106, metadata storage device 114, lock manager 124, data storage engine 118, query execution engine 120 and transaction manager 122 may include data centers in a distributed data center set.

[0041] In this embodiment, each of clients 104 and 106 cleans up (multiple) the same user databases, performs updates on these databases, and has access to data and / or metadata up to any previous point in time. Furthermore, as will be described below, the schema of an object in any database can be modified by one of clients 104 or 106 while another client (not shown) is running concurrent queries scanning the same schema. Such changes and deletions are typically performed by executing DDL operations. For example, as will be described below, a user of client 104 or client 106 can connect to the execution environment 108 of the relational database system and execute T-SQL DDL statements. The relational database system 100 can perform changes / deletions by executing commands within a transaction. As mentioned above, such transactions must conform to ACID, as will be described in detail below.

[0042] As described above, the data and / or metadata modifications performed by relational database system 100 are performed within the context of ACID-compliant transactions, and relational database system 100 is ACID-compliant. As is known in the art, ACID is an acronym representing a set of properties of database transactions that ensure that data (or metadata) persisted to the database remains valid even if errors occur due to, for example, hardware failure or power failure. The ACID properties are: Atomicity, Consistency, Isolation, and Durability. Transactions performed by relational database system 100 are ACID-compliant because the logically corresponding operations of the transaction collectively satisfy the ACID properties.

[0043] The atomicity property of transactions requires that a transaction either succeeds completely or fails completely. Complete failure of a transaction means that the database remains unchanged. For example, suppose a transaction involves transferring funds from account A to account B. The entire transaction includes the following steps: debiting funds from account A, transferring funds to any location within account B, and crediting funds to account B. In this case, atomicity guarantees that even if, for any reason, the funds are not credited to account B, funds will not be debited from account A.

[0044] The consistency property ensures that transactions conform to all applicable rules (which govern the storage of data) so that transactions can transition the database from one valid state to another.

[0045] Isolation ensures that different transactions executed concurrently maintain the database in the same state as if the transactions were executed sequentially. Isolation is a primary objective of concurrency control, and the embodiments discussed below utilize a relational database system 100 to implement such concurrency control for metadata operations.

[0046] Finally, the durability property guarantees that once a transaction is committed (i.e., completed and persisted to the database in an ACID-compliant manner), the transaction will remain committed, and no hardware, system, or power failure can cause the transaction to be lost or cause the database to enter another inconsistent state. See also... Figure 1 The ACID properties of transactions executed by the relational database system 100 are partly ensured by using log recording of the execution as follows.

[0047] To maintain the ACID properties of transactions, embodiments of the relational database system 100 can be configured to generate a transaction log record upon transaction commit and store this record in a transaction log before any data modifications caused by the transaction are written to disk. In embodiments, the log record can be processed individually or in combination with, for example, by a transaction manager 122 or a data storage engine 118. However, in other embodiments, a dedicated logging component can be used ( Figure 1 (not shown in the image) is used to manage the storage and retrieval of such transaction logs.

[0048] The log entries for committed transactions include all the information necessary to re-execute the transaction should a problem occur (e.g., a power failure) before the data modified by the transaction is stored (e.g., in data storage engine 118). The log entries may include information including (but not limited to) a transaction identifier, log sequence number, timestamp, information indicating which data objects(s) were modified and how they were modified, etc. In this embodiment, the log entry information is managed and / or provided by the transaction manager 122.

[0049] In an embodiment, transaction manager 122 may be configured to maintain transaction IDs and start times for transactions. Transaction manager 122 may be centralized and available to provide transaction services for all clients and / or replicas of relational database system 100. An embodiment may be configured to obtain a list of active and terminated transactions from transaction manager 122 up to any given time, and to use this information for versioning purposes, as described below. Furthermore, an embodiment may acquire locks via lock manager 124 as needed. Such locks will now be described further.

[0050] Relational database systems use locks to maintain a consistent state of a database by ensuring that any read, scan, or other use of a metadata object reflects its valid state. Traditional relational database systems do not provide versioned metadata; therefore, only one valid state can exist for a metadata object. For traditional relational database systems, and as described above, the result is that a metadata object being scanned or otherwise read simultaneously cannot be modified, and similarly, a metadata object being modified cannot be scanned or otherwise read. Locks are the mechanism that enforces these restrictions.

[0051] For example, suppose a metadata modification command (i.e., DDL) is being executed within a transaction. To enforce the constraints of a typical relational database system as described above, executing DDL will require locks on the metadata object(s) being modified. Before such a modification, the relational database system will request an exclusive schema modification lock (referred to as "SCH-M") from a component such as lock manager 124 or a similar component. Lock manager 124 will only provide and enforce this lock after ensuring that no other transaction is reading or scanning the metadata object to be modified. Similarly, reading / scanning the metadata object also requires a lock that will prevent metadata modification from occurring. This type of lock is called a schema stability (SCH-S) lock.

[0052] Therefore, SCH-M locks and SCH-S locks are mutually exclusive. That is, a lock manager (such as lock manager 124) will not issue architectural change DDLs for SCH-M locks until no SCH-S locks are incomplete. Similarly, no SCH-S locks will be provided until no SCH-M locks are incomplete. For a conventional system, the overall result is that metadata reads and writes are mutually exclusive and cannot be performed concurrently. On the other hand, embodiments of this disclosure allow metadata reads and writes to be performed concurrently by using versioned metadata and by introducing new lock types.

[0053] Versioned snapshot isolation of metadata transactions is supported by maintaining transaction versions for each metadata version in metadata storage 114 and in metadata cache 116 within metadata storage 114. Metadata cache 116 provides high-speed access to metadata objects and their various versions, while metadata storage 114 includes physical storage in non-volatile memory. Of course, the contents of high-speed metadata cache 116 must be kept synchronized with physical records stored elsewhere in metadata storage 114.

[0054] Versioned snapshot isolation of metadata transactions is further supported by providing a way to determine which version of a metadata object is visible to a given transaction. In an embodiment, transaction manager 122 may maintain a transaction visibility list for each transaction, specifying which transactions are visible to that transaction, and thus which metadata version(s) are visible to that transaction. However, in other embodiments, some combinations of transaction manager 122, metadata storage device 114, data storage engine 118, and / or lock manager 124 may be configured individually or in combination to enable embodiments to determine which versions of metadata objects are available for a particular transaction. Therefore, versioned snapshot isolation is supported in the following general manner.

[0055] When modifying or deleting metadata, the versioning framework of embodiments of this disclosure invokes a copy-on-write mechanism. This requires that, while the transaction performing such modification or deletion is still running, older versions of the metadata must be available for transactions requiring an early transactional consistency state. Therefore, when supporting versioned isolation levels, the metadata storage device 114 stores a version of the metadata object each time it is modified. For example, each new version of the metadata object can be stored along with the transaction identifier and commit timestamp of the committed modified transaction, allowing embodiments to determine the point in time when a given version was generated. Alternatively, the committed transaction ID and associated timestamp can be maintained separately from the version corresponding to the committed transaction.

[0056] Figure 3 as well as Figure 4 An example logical timeline of concurrent metadata read and write transactions under two different snapshot isolation schemes, according to an example embodiment, is depicted. Specifically, Figure 3 Example logical timeline 300 depicts concurrent data read and metadata modification transactions using example snapshot isolation 314, while Figure 4 Example logical timeline 400 depicts concurrent data read and metadata modification transactions using committed read snapshot isolation 414. Figure 3 Snapshot isolation 314 and Figure 4 The differences between committed read snapshot isolation 414 are described below.

[0057] Regarding snapshot isolation 314 and read committed snapshot isolation 414, the term "snapshot" reflects the fact that, based on the state of the database at the start of a transaction, all queries within the transaction see (are applied to) the same version of the database, or "snapshot." The term "isolation" reflects the fact that different transactions seeing different versions of the database can still run concurrently because snapshots effectively isolate such transactions from each other.

[0058] The difference between Read Committed snapshot isolation and snapshot isolation is that in Read Committed snapshot isolation, version visibility is limited to the statement level, while in snapshot isolation, this visibility is limited to the transaction level. Further consideration... Figure 3 as well as Figure 4 This difference will become even more apparent. Figure 3 The timeline 300 is described as a table with rows and columns, where the time axis extends vertically from top to bottom along the table. That is, moving from one row down to the next is equivalent to moving forward in time (i.e., moving the table down means moving forward in time). Figure 3 The timeline 300 includes the following: metadata modification command 302, lock type 304, time 306, data read command 308, lock type 310, and comment 312.

[0059] Figure 3 Metadata modification command 302 describes a transaction that modifies metadata. Specifically, the ALTER TABLE statement at time=T6 adds a new column to a table named 'Employees', which modifies the metadata object associated with the 'Employees' table. The transaction against the ALTER TABLE command starts at time=T4 and commits at time=T9.

[0060] Figure 3 Data read command 308 comprises two transactions. The first transaction starts at time = T1 and commits at time = T12, while the second transaction starts at time = T13 and commits at time = T15. The first transaction includes two SELECT statements, which are executed at time = T2 and time = T10, and read the data and metadata. According to snapshot isolation semantics, the SELECT statement executed at time = T2 cannot see the new column 'RemainingSickDays' added by metadata modification command 302 because the change caused by metadata modification command 302 does not exist until its corresponding transaction commits at time = T9.

[0061] The second SELECT statement is executed within the first transaction at time T10. Note that time T10 is after metadata modification command 302 has been committed, therefore theoretically, the modified metadata should be available to statements executed after that point in time. However, regarding Snapshot isolation The visibility of metadata modifications is limited to Transaction level Scope. Therefore, during a transaction, the visible metadata version cannot change, and the visible metadata version is fixed to a specific range. transactions The point in time when it starts up. (Continue referring to...) Figure 3 The second transaction started at time T13 really The modified metadata is visible because the transaction was started long after the transaction of metadata modification command 302 was committed (at time=T9) (at time=T13).

[0062] On the other hand, Read snapshot isolation has been committed In this context, the visibility of metadata modifications is limited to the statement level, not the transaction level. This difference is now referenced... Figure 4 The timeline 400 is described, and includes the following: metadata modification command 402, lock type 404, time 406, data read command 408, lock type 410, and comment 412.

[0063] Figure 4 Metadata modification command 402 describes a transaction that modifies metadata. Specifically, the ALTER TABLE statement at time = T5 adds a new column to a table named 'Employees', which modifies the metadata object associated with the 'Employees' table. The transaction against the ALTER TABLE command starts at time = T3 and commits at time = T11.

[0064] Figure 4 The data read command 408 comprises a transaction executing three SELECT statements. This transaction starts at time = T1 and commits at time = T13. The first SELECT statement begins execution at time = T2 and completes at time = T9. The second SELECT statement executes at time = T10, and the third SELECT statement executes at time = T12. Of course, the result of the metadata modification command 402 may not be visible to any of the transactions or statements until its transaction commits at time = T11. Therefore, the new column added by the ALTER TABLE statement at T=T5 is not visible to either of the first two SELECT statements that started at time = T2 and time = T10. However, the SELECT statement executed at time = T12 is part of the metadata modification command transaction that started at time = T11. after It was just executed. Because of this, and also because example 402 is using committed read snapshot isolation, the new column added by the metadata modification command 402 is at time = T12 for the SELECT statement. yes This is visible. This is because in read committed snapshot isolation, for transactions... Each statement Visibility will be determined in both cases. On the other hand, in snapshot isolation, visibility is determined for... The whole transaction It is determined by the statement itself, rather than by the individual statements within the transaction.

[0065] In this embodiment, the SELECT statement or data read command 408 executed at time T10 generates a query plan, which is then optimized by the binding / algebraizer / query optimizer 112. Subsequently, the query plan is executed by the query execution engine 120. In this embodiment, the compiled query plan is cached and reused in subsequent executions of the same statement. (Continuing to refer to...) Figure 4 Although the SELECT statement executed at time=T12 is the same as the statement executed at time=T10, the query plan compiled for the latter SELECT statement is unusable because it references an older version of the metadata corresponding to the "Employees" table before the new column was added by the ALTER TABLE command at time=T5. The implementation will detect that the cached query plan generated when the SELECT statement was executed at time=T10 is actually outdated because it references the wrong version of the metadata. Therefore, the implementation will recompile the query plan to reference the correct version(s) of the metadata. The recompiled query plan can then be executed, and as depicted in the data read command 408 at time=T12, which will show that the new column added by the ALTER TABLE command 402 of the metadata modification command is indeed visible.

[0066] Figure 3 and Figure 4 Example logical timelines 300 and 400 also include lock type columns 304, 310, 404, and 410, respectively. The lock type columns reflect the type of locks requested and held by statements within a transaction. As mentioned above, traditional lock types include schema-modification locks (SCH-M) and schema-stability locks (SCH-S). Embodiments of the relational database system 100 also include and use these types of locks. This is correct because some metadata modification commands (i.e., DDL commands) are neither compatible with versioned metadata nor utilize versioned data, and also because some metadata operations should and / or must have exclusive access to metadata objects.

[0067] For these reasons, the implementation provides two new lock types, referred to as the access schema version and the creation schema version, denoted as 'SCH-A' and 'SCH-C', respectively. These lock types are used for version-aware and compatible statements and DDL operations (e.g., the aforementioned ALTER TABLE and / or SELECT). Because versioned metadata is used, full and exclusive access to metadata objects is no longer required. Statements requesting and receiving a SCH-A lock from, for example, lock manager 124, will automatically see the metadata version visible to them when execution begins. Similarly, statements requesting and receiving a SCH-C lock (such as ALTER TABLE) can modify metadata objects without being blocked by the corresponding read, provided that the result of ALTER TABLE is a new version of the metadata object. Therefore, there are no conflicts between locks, and these locks do not block other locks, ensuring the database remains ACID-compliant and maintains a consistent state.

[0068] In this embodiment, the schema-modification lock (SCH-M) is acquired during the execution of a DDL statement and prevents access to the locked object's data because the object's structure is being modified. SQL Server allows a single schema-modification lock (SCH-M) on any locked object. A schema-stability lock (SCH-S) is acquired during the compilation and execution of schema-dependent queries and the generation of execution plans. This lock does not prevent other transactions from accessing the object's data.

[0069] Regarding SCH-A (Access Schema Version) and SCH-C (Create Schema Version), the implementation can support and / or implement various types of constraints or functions, such as:

[0070] 1. Not all DDL operations support metadata versioning.

[0071] 2. No concurrent DDL operations (i.e., only one DDL operation per object at a time), regardless of whether the operation supports versioning.

[0072] 2. Data Manipulation Language (“DML”) operations, such as insert, update, delete, or merge, are not permitted while architectural changes are in progress. That is, no DML operations are permitted when there are pending (uncommitted) DDL changes.

[0073] 3. Snapshot queries are allowed in snapshot isolation or read-committed snapshot isolation when there is an ongoing DDL operation. Other isolation levels are blocked.

[0074] 4. Some operations cannot or will not support versioning, and should even prevent snapshot queries. For example, such operations may include DBCC SHRINK. During DBCC SHRINK, the operation affects the physical structure of the index, such as when moving index allocation mapping (“IAM”) pages. Therefore, a SCH-M lock is acquired. Furthermore, a subset of DDL operations (primarily adding and deleting columns) can be supported, as well as incremental operations. In this embodiment, any unsupported DDL operation (such as renaming a column) can retain the old blocking semantics.

[0075] How the new lock pattern interacts with existing architectural locks:

[0076] SCH-A: Indicates that the query requires versioned architectural stability. SCH-A is obtained through a snapshot query currently using SCH-S, and conflicts with the SCH-M lock, which is still obtained through all DDL operations that do not support versioning.

[0077] SCH-C: Indicates versioned schema modifications and those obtained through DDL operations that support schema versioning, such as ADD COLUMN. This is less restrictive than SCH-M because it is compatible with SCH-A, but still not with SCH-S.

[0078] Locking modes related to architectural changes and stability can include the following (from least exclusive to most exclusive):

[0079] SCH-A: Obtained through a snapshot query that uses SCH-S, meaning all SIs will use SCH-A locks.

[0080] SCH-S: Acquired through all other operations that use it today, such as NOLOCK scanning, etc.

[0081] It's worth noting that although SCH-A can be considered the weakest lock (under the new locking architecture), SCH-S is still acquired for NOLOCK table scans to prevent architecture changes while the scan is in progress. Data access locks (such as IS, IX, etc.) are still used by other isolation levels, such as read committed. SCH-C: Acquired through support for versioned DDL operations, but snapshot queries that now use SCH-A are supported. SCH-M: Acquired through non-versioned DDL operations and blocks everything, such as DBCC Shrink.

[0082] Table 1 below shows the compatibility matrix for snapshot queries (C – conflict, N – no conflict): Table 1

[0083] Other changes may include:

[0084] 1. In the storage engine, when accessing HoBt (heap or B-tree) metadata, obtain SCH-S. As metadata is versioned, switch snapshot access calls from SCH-S to SCH-A.

[0085] 2. Similarly, for system table-level snapshot access, acquire a SCH-A lock instead of a SCH-S lock.

[0086] 3. For query compilation, use RCSI semantics and SCH-A locks instead of SCH-S locks. During execution, if a user transaction is not running at the SI / RCSI level, the query can be recompiled based on the current object version.

[0087] Figure 5A , Figure 5B , Figure 5C as well as Figure 6 Flowcharts 500, 510, 530, and 600 respectively illustrate example methods for modifying metadata objects in a relational database system without being blocked by concurrent read access to the metadata objects, according to embodiments. Flowcharts 500, 510, 530, and 600 respectively illustrate operations similar to those described above in this document. Figure 3 as well as Figure 4 The example logical timeline 300 and example logical timeline 400 describe the methods for snapshot isolation scenarios and committed read snapshot isolation scenarios. In the embodiments, flowcharts 500, 510, 530, and 600 can be derived from... Figure 1 The relational database system 100 executes. (Although references are available...) Figure 1 The system 100 shown and Figure 3 The logical timeline 300 is shown as the description, but flowcharts 500, 510, 530, and 600 are not limited to this implementation. Based on the following... Figure 5A , Figure 5B , Figure 5C and Figure 6 The discussion of flowcharts 500, 510, 530 and 600 will make other structural and operational embodiments obvious to those skilled in the art.

[0088] like Figure 5AAs shown, flowchart 500 begins at step 502. In step 502, a data read command is received, which includes a first query and a second query, each query referencing metadata objects in the metadata storage of the relational database system, and user data objects configured to read from the user data storage of the relational database system. For example, client 104 can send a command to relational database system 100, such as... Figure 1 As shown. More specifically, client 104 can send data read command 308 or data read command 408 respectively, such as Figure 3 and Figure 4 As shown, the command is received by parser 110 within execution environment 108. Data read command 308 and data read command 408 each include a first query and a second query in the form of SELECT statements pointing to the employee table, respectively, which are executed starting at time T2 and time T10. Processing such queries in execution environment 108 requires that the metadata object reference the metadata corresponding to the employee table. Flowchart 500 continues at step 504.

[0089] In step 504, a metadata modification command to be executed concurrently with the data read command is received, wherein the execution of the metadata modification command causes a metadata object stored in the metadata storage device of the relational database system to be modified. For example, and continuing to refer to Figure 1 , Figure 3 as well as Figure 4 Client 106 can send separately Figure 3 or Figure 4 Metadata modification command 302 or 402, shown, is received by parser 110 within execution environment 108. Metadata modification command 302 or 402 includes an ALTER TABLE command, which is executed at time T6 or T5 respectively, and adds the RemainingSickDays column to the employee table. Processing this ALTER modifies the metadata corresponding to the employee table. Flowchart 500 continues at step 506.

[0090] In step 506, in response to receiving a data read command, the first query is executed in the first transaction. Continue to refer to... Figure 1 , Figure 3 as well as Figure 4 Data read command 308 or data read command 408 executes each query in the first query and the second query within the transaction, which begins at time T1 and is committed at time T12 or T13, respectively. Flowchart 500 ends at step 508.

[0091] In step 508, in response to receiving the metadata modification command, the metadata object is modified in the second transaction, concurrently with the modification in the first transaction, provided that the first query executed in the first transaction does not prevent it. Continue to refer to... Figure 3 and Figure 4 The ALTER TABLE commands, executed at times T6 or T5 respectively, are executed within a transaction, which begins at time T4 or T5 and commits at time T9 or T11 respectively. Data read commands 308 and 408 are obtained and used respectively. Figure 3 and Figure 4 The "Lock Type" column 310 or "Lock Type" column 410 respectively indicates the schema access lock SCH-A. The ALTER TABLE command is used to obtain and use... Figure 3 and Figure 4 The columns “Lock Type” 304 and 404 respectively indicate the schema change lock SCH-C. As mentioned above, a SCH-A lock does not prevent a SCH-C lock, and ALTER TABLE can be executed concurrently with the query executed by the data read command 308.

[0092] In the discussion of steps 502 to 508 of flowchart 500 above, it should be understood that such steps may sometimes be executed in a different order, or even simultaneously with other steps. For example, a SELECT statement that begins execution at time T2 may begin execution at a different time. Other operational embodiments will be apparent to those skilled in the art. It should also be noted that the general description of the relational database system 100 above is provided for illustrative purposes only, and embodiments of the relational database system 100 may include different hardware and / or software, and may operate in ways different from those described above. In fact, the steps of flowchart 500 can be executed in a variety of ways.

[0093] For example, Figure 5B A flowchart 510 is depicted illustrating an example method for operating a relational database system to modify metadata objects without being blocked by concurrent read access to the metadata objects, according to an embodiment, and wherein the flowchart 510 includes... Figure 5A The flowchart 500 shown is a refinement or addition of the method steps. Therefore, Figure 5B Flowchart 510 will continue to refer to Figure 1 as well as Figure 3 as well as Figure 4 The relational database system 100 is described. However, based on the following discussion of flowchart 510, other structures and operational embodiments will be apparent to those skilled in the art.

[0094] like Figure 5B As shown, flowchart 510 begins at step 512. In step 512, the first transaction is initiated at time T1. For example, and continuing to refer to... Figure 3 At time 300, data read command 308 initiates a transaction at time T1 on the timeline represented by time column 306. Flowchart 510 continues in step 514.

[0095] In step 514, a metadata access lock is obtained from the lock manager of the relational database system. For example, a SELECT statement of a data read command 308 executed at time T2 on the timeline represented by time column 306 obtains a SCH-A lock from the lock manager 124 within the execution environment 108 of the relational database system 100, as further described herein. Flowchart 510 continues in step 516.

[0096] In step 516, a first query plan is created for the first query, wherein the first query plan references a metadata object. (See also...) Figure 1 When processing data read command 308 within execution environment 108, parser 110, in conjunction with binder / algebraizer / query optimizer 112, will create a query plan that references the correct metadata object corresponding to the snapshot created at the start of the transaction. More specifically, the query plan for the SELECT statement of data read command 308 executed at time T2 on the timeline shown in time column 306 will reference the metadata of the employee table existing in the snapshot created at time T1 at the start of the transaction. Flowchart 510 continues at step 518.

[0097] In step 518, using the first metadata access lock, execution of the first query plan begins within the first transaction at time T2. For example, the query plan for the SELECT statement of the data read command 308, which begins execution at time T2 on the timeline represented by time column 306, is submitted to the query execution engine 120 (e.g., ...). Figure 1 (as shown), and this query plan begins execution. Flowchart 510 ends at step 516.

[0098] In step 520, the execution of the first query plan is completed at time T3. Continue to refer to... Figure 3 The SELECT statement of data read command 308, which starts executing at time T2 on the timeline represented by time column 306, completes execution at time T9 on the timeline shown in time column 306. Therefore, time T3 corresponds to time T9 on the timeline shown in time column 306.

[0099] In step 522, the first transaction is committed at time T4. For example, the transaction that started at time T1 on the timeline represented by time column 306 is committed at time T12 on the same timeline. Therefore, in this example, time T4 is time T12 on the timeline represented by time column 306.

[0100] In the discussion of steps 512 to 522 of flowchart 510 above, it should be understood that such steps may sometimes be executed in a different order, or even simultaneously with other steps. For example, a SELECT statement that begins execution at time T2 may begin execution at a different time. Other operational embodiments will be apparent to those skilled in the art. It should also be noted that the general description of the relational database system 100 above is provided for illustrative purposes only, and embodiments of the relational database system 100 may include different hardware and / or software, and may operate in a manner different from that described above.

[0101] Figure 5C The embodiments of the above are described. Figure 5A as well as Figure 5B A detailed flowchart of the method described herein is provided in flowchart 530. Therefore, Figure 5B Flowchart 530 continues to refer to Figure 1 Relational database system 100 and Figure 3 as well as Figure 4 Description. However, based on the following discussion of flowchart 530, other structures and operational embodiments will be apparent to those skilled in the art.

[0102] like Figure 5C As shown, flowchart 530 begins at step 532. In step 532, at time T5, the second transaction starts concurrently with the first transaction. For example, and referring to... Figure 3 Timeline 300, metadata modification command 302 includes a transaction that begins at time T4 on the timeline represented by time column 306. Therefore, for example, time T5 in flowchart 530 can correspond to time T4 on the timeline shown in time column 306. The flowchart continues to step 534.

[0103] In step 534, a metadata modification lock is obtained from the lock manager. For example, an ALTER TABLE statement of metadata modification command 302 executed at time T6 on the timeline shown in time column 306 obtains an SCH-C lock from the lock manager 124 within the execution environment 108 of the relational database system 100, as further described herein. Flowchart 530 continues to step 536.

[0104] In step 536, the metadata object is modified within the second transaction using a metadata change lock, where the modification is not blocked by a metadata access lock. See also... Figure 3 The ALTER TABLE command executed at time T6 acquires the SCH-C lock, while the data read command 308 acquires and uses... Figure 3 The schema access lock SCH-A is indicated in column "Lock Type" 310. As mentioned above, the SCH-A lock does not prevent the SCH-C lock, and ALTER TABLE can be executed concurrently with the query executed by the data read command 308. Flowchart 530 ends at step 538.

[0105] In step 538, the second transaction is committed at time T6. Continue to refer to... Figure 3 The ALTERTABLE command executed at time T6 is performed within a transaction that begins at time T4 and commits at time T9. Therefore, time T6 corresponds to time T9 shown on the timeline in time column 306.

[0106] In the discussion of steps 533 to 538 of flowchart 530 above, it should be understood that such steps may sometimes be performed in a different order, or even simultaneously with other steps. Other operational embodiments will be apparent to those skilled in the art. It should also be noted that the general description of the relational database system 100 above is provided for illustrative purposes only, and embodiments of the relational database system 100 may include different hardware and / or software, and may operate in ways different from those described above. In fact, the steps of flowcharts 500, 510, and 530 can be performed in a variety of ways.

[0107] For example, Figure 6 Flowchart 600 illustrates an example refinement of flowcharts 500, 510, and / or 530, where the embodiment operates in a committed read snapshot isolation mode. In this mode, metadata object version visibility and new snapshot creation are performed on each command within a transaction, rather than being entirely confined to the transaction scope. Flowchart 600 begins at step 602. In step 602, at a time prior to T6, a second query is executed within the first transaction, thereby compiling a second query plan that references the first version of the metadata object. For example, and referring to... Figure 4Data read command 408 includes a first SELECT statement that begins execution at time T2 as shown in time column 406. This query will cause a query plan to be created for execution. Similarly, the SELECT statement of data read command 408 that begins execution at time T10 as shown in time column 406 will cause a different query plan to be created because the queries are different. In each case, the transaction of metadata modification command 402 has not been completed when such a SELECT statement begins execution. Therefore, such a query will see a snapshot that references the version of the metadata of the employee table that existed when such a SELECT statement was initiated. Flowchart 600 ends at step 604.

[0108] In step 604, at a time after time T6, the second query is executed again within the first transaction, causing the second query plan to be recompiled to generate a third query plan, which references the second version of the metadata object. (Continue to...) Figure 4 The SELECT statement executed at time T10 is executed again at time T12. However, because the metadata modification command 402 transaction is committed at time T11, the SELECT statement executed at time T12 cannot use the same query plan, as this query plan references an older version of the metadata corresponding to the employee table. Instead, the implementation creates a new snapshot that references a second version of the metadata for the employee table, where the new RemainingSickDays column is actually visible.

[0109] The scenario described in flowchart 600 is not applicable, as the embodiments operate in snapshot isolation mode, such as... Figure 3 Example timeline 300 is shown. In this case, and as mentioned above, the visibility of metadata modifications is always limited to the transaction level, not the statement level within the transaction. Therefore, in, for example, a transaction (that transaction is in Figure 3 Each statement executed within the time frame (starting from time T1 as shown in time column 306) will see the metadata version that existed when the transaction started. even though Metadata modification commands executed concurrently can be committed within the data read command transaction. Before implement.

[0110] In the discussion of the steps in flowcharts 500, 510, 530, and 600 above, it should be understood that such steps may sometimes be performed in a different order, or even simultaneously with other steps. It should also be noted that the general description of the relational database system 100 above is provided for illustrative purposes only, and embodiments of the relational database system 100 may include different hardware and / or software, and may operate in a manner different from that described above. III. Example Computer System Implementation

[0111] Each of the relational database system 100, client 104, client 106, binder / algebraizer / query optimizer 112, parser 110, lock manager 124, metadata storage device 114, metadata cache 116, data storage engine 118, query execution engine 120, and / or transaction manager 122, as well as flowcharts 500, 510, and / or 530, can be implemented in hardware or in hardware combined with software and / or firmware. For example, the relational database system 100, client 104, client 106, binder / algebraizer / query optimizer 112, parser 110, lock manager 124, metadata storage device 114, metadata cache 116, data storage engine 118, query execution engine 120, and / or transaction manager 122, as well as flowcharts 500, 510, and / or 530, can be implemented as computer program code / instructions configured to execute in one or more processors and stored in a computer-readable medium. Alternatively, the relational database system 100, client 104, client 106, binder / algebraizer / query optimizer 112, parser 110, lock manager 124, metadata storage device 114, metadata cache 116, data storage engine 118, query execution engine 120 and / or transaction manager 122, and flowcharts 500, 510, 530 and / or flowchart 600 can be implemented as hardware logic / electrical circuits.

[0112] For example, in an embodiment, one or more of the following (in any combination): relational database system 100, client 104, client 106, binder / algebraizer / query optimizer 112, parser 110, lock manager 124, metadata storage device 114, metadata cache 116, data storage engine 118, query execution engine 120, and / or transaction manager 122, as well as flowcharts 500, 510, and / or 530, may be implemented together in a SoC. The SoC may include an integrated circuit chip that includes a processor (e.g., a central processing unit (CPU), microcontroller, microprocessor, digital signal processor (DSP), one or more graphics processing units (GPUs), etc.), memory, one or more communication interfaces, and / or one or more additional circuitry, and may optionally execute received program code and / or include embedded firmware to perform functions.

[0113] Figure 7Exemplary implementations of computing device 700, in which embodiments may be implemented, are depicted. For example, relational database system 100, client 104, client 106, binder / algebraizer / query optimizer 112, parser 110, lock manager 124, metadata storage device 114, metadata cache 116, data storage engine 118, query execution engine 120, and / or transaction manager 122 may be implemented in one or more computing devices similar to computing device 700 in a fixed or mobile computing environment, including one or more features and / or alternative features of computing device 700. The description of computing device 700 provided herein is provided for illustrative purposes and is not intended to be limiting. Embodiments may be implemented in other types of computer systems, as known to those skilled in the art.

[0114] Computing device 702 can be any of a variety of computing devices. For example, computing device 702 can be a mobile computing device, such as a handheld computer (e.g., a personal digital assistant (PDA)), laptop, tablet computer (such as the Apple iPad™), hybrid device, laptop computer (e.g., Google Chromebook™), netbook, mobile phone (e.g., a cellular phone, smartphone (such as Apple® iPhone®, a phone implementing the Google® Android™ operating system), wearable computing device (e.g., head-mounted augmented reality and / or virtual reality devices, including smart glasses such as Google® Glass™, Facebook Technologies' Oculus Rift®), or other types of mobile computing devices. Alternatively, computing device 702 can be a fixed computing device, such as a desktop computer, personal computer (PC), fixed server equipment, minicomputer, mainframe, supercomputer, etc.

[0115] like Figure 7As shown, computing device 702 includes various hardware and software components, including a processor 710, storage device 720, one or more input devices 730, one or more output devices 750, one or more wireless modems 760, one or more wired interfaces 780, power supply 782, location information (LI) receiver 784, and accelerometer 786. Storage device 720 includes memory 756 (which includes non-removable memory 722 and removable memory 724) and storage device 790. Storage device 720 also stores operating system 712, applications 714, and application data 716. Multiple wireless modems 760 include Wi-Fi modem 762, Bluetooth modem 764, and cellular modem 766. Multiple output devices 750 include speakers 752 and a display 754. Multiple input devices 730 include a touchscreen 732, microphone 734, camera 736, physical keyboard 738, and trackball 740. Figure 7 Not all components of the computing device 702 shown are present in all embodiments; additional components not shown may also be present, and in certain embodiments, any combination of components may be present. These components of the computing device 702 are described below.

[0116] In computing device 702, there may be a single processor 710 (e.g., a central processing unit (CPU), microcontroller, microprocessor, signal processor, ASIC (Application-Specific Integrated Circuit), and / or other physical hardware processor circuitry) or multiple processors 710 for performing tasks such as program execution, signal encoding, data processing, input / output processing, power control, and / or other functions. Processor 710 may be a single-core processor or a multi-core processor, and each processor core may be single-threaded or multi-threaded (to provide multiple threads to execute concurrently). Processor 710 is configured to execute program code stored in a computer-readable medium, such as program code for operating system 712 and application program 714 stored in storage device 720. Operating system 712 controls the allocation and use of components of computing device 702 and provides support for one or more application programs 714 (also referred to as "applications" or "apps"). Application 714 may include common computing applications (e.g., email applications, calendars, contact managers, web browsers, messaging applications), other computing applications (e.g., word processing applications, map applications, media player applications, productivity suite applications), one or more machine learning (ML) models, and applications related to embodiments disclosed elsewhere herein.

[0117] Any component in computing device 702 can communicate with any other component according to its function, although not all connections are shown for ease of illustration. For example, such as Figure 7 As shown, bus 706 is a multi-signal-line communication medium (e.g., conductive lines in silicon, metal traces along the motherboard, wires, etc.) whose purpose is to communicatively couple processor 710 to other components of computing device 702, although in other embodiments, alternative buses, additional buses, and / or one or more individual signal lines may be present for communicatively coupling components. Bus 706 represents one or more bus structures of any type, including a memory bus or memory controller, a peripheral bus, an accelerated graphics port, and a processor or local bus using any of the various bus architectures.

[0118] Storage device 720 is a physical storage device that includes one or both of memory 756 and storage device 790, used to store operating system 712, application program 714, and application data 716 according to any distribution. Non-removable memory 722 includes one or more of the following: RAM (Random Access Memory), ROM (Read Only Memory), flash memory, solid-state drive (SSD), hard disk drive (e.g., a hard disk drive for reading from and writing to the hard disk), and / or other physical storage device types. Non-removable memory 722 may include main memory and may be separate from or fabricated within the same integrated circuit as processor 710. Figure 7 As shown, non-removable memory 722 stores firmware 718, the purpose of which may be to provide low-level control of the hardware. Examples of firmware 718 include BIOS (Basic Input / Output System, such as on a personal computer) and boot firmware (e.g., on a smartphone). Removable memory 724 may be inserted into or otherwise coupled to computing device 702, and may be removed by a user from computing device 702. Removable memory 724 may include any suitable type of removable memory device, including SD (Secure Digital) cards, Subscriber Identity Module (SIM) cards (which are well known in GSM (Global System for Mobile Communications) communication systems), and / or other types of removable physical memory devices. One or more storage devices 790 may be present, located inside or outside the housing of computing device 702, and these storage devices 790 may be removable or not. Examples of storage devices 790 include hard disk drives, SSDs, thumb drives (e.g., USB (Universal Serial Bus) flash drives), or other physical storage devices.

[0119] One or more programs may be stored in storage device 720. Such programs include operating system 712, one or more application programs 714, and other program modules and program data. For example, examples of such application programs may include computer program logic (e.g., computer program code / instructions) for implementing one or more of relational database system 100, client 104, client 106, binder / algebraizer / query optimizer 112, parser 110, lock manager 124, metadata storage device 114, metadata cache 116, data storage engine 118, query execution engine 120 and / or transaction manager 122, as well as flowcharts 500, 510, 530, and / or flowchart 600 (including any suitable steps of flowcharts 500, 510, 530 and / or 600) and / or other embodiments described herein.

[0120] Storage device 720 also stores data used and / or generated by operating system 712 and application 714 as application data 716. Examples of application data 716 include web pages, text, images, tables, sound files, video data, and other data, which can also be sent to and / or received from one or more network servers or other devices via one or more wired or wireless networks. Storage device 720 can be used to store additional data, including user identifiers (such as International Mobile Subscriber Identity (IMSI)) and device identifiers (such as International Mobile Equipment Identity (IMEI)). Such identifiers can be sent to network servers to identify users and devices.

[0121] Users can input commands and information into computing device 702 through one or more input devices 730, and can receive information from computing device 702 through one or more output devices 750. The input devices 730 may include one or more of a touchscreen 732, microphone 734, camera 736, physical keyboard 738, and / or trackball 740, and the output devices 750 may include one or more of a speaker 752 and display 754. Each of the input devices 730 and output devices 750 may be integrated with computing device 702 (e.g., built into the housing of computing device 702) or located outside computing device 702 (e.g., communicatively coupled to computing device 702 via wired interfaces 780 and / or wireless modems 760 in a wired or wireless manner). Other input devices 730 (not shown) may include natural user interfaces (NUIs), pointing devices (computer mice), joysticks, video game controllers, scanners, touchpads, styluses, voice recognition systems for receiving voice input, gesture recognition systems for receiving gesture input, etc. Other possible output devices (not shown) may include piezoelectric or other haptic output devices. Some devices may have more than one input / output function. For example, a display 754 may display information and be operated as a touchscreen 732 by receiving user commands and / or other information (e.g., via touch, finger gestures, virtual keyboard, etc.). Any number of each type of input device(s) 730 and output device(s) 750 may be present, including multiple microphones 734, multiple cameras 736, multiple speakers 752, and / or multiple displays 754.

[0122] One or more wireless modems 760 may be coupled to multiple antennas (not shown) of computing device 702 and may support bidirectional communication between processor 710 and devices external to computing device 702 via network 704, as understood by those skilled in the art. Wireless modems 760 are shown in a general form and may include cellular modems 766 for communicating with one or more cellular networks, such as GSM networks for data and voice communication within a single cellular network, between cellular networks, or between a mobile device and the Public Switched Telephone Network (PSTN). Wireless modems 760 may also include, or alternatively include, other radio-based modem types, such as Bluetooth modem 764 (also referred to as a "Bluetooth device") and / or Wi-Fi modem 762 (also referred to as a "wireless adapter"). Wi-Fi modem 762 is configured to communicate with access points or other Wi-Fi-enabled remote devices based on the IEEE (Institute of Electrical and Electronics Engineers) 802.11 series of standards (typically used for local area network connections and Internet access of devices), according to one or more protocols in the Wireless Network Protocol. The Bluetooth modem 764 is configured to communicate with another Bluetooth-enabled device in accordance with (multiple) Bluetooth short-range wireless technology standards (such as IEEE 802.15.1) and / or be managed by the Bluetooth Special Interest Group (SIG).

[0123] The computing device 702 may also include a power supply 782, an LI receiver 784, an accelerometer 786, and / or one or more wired interfaces 780. Example wired interfaces 780 include USB ports, IEEE 794 (firewall) ports, RS-232 ports, HDMI (High-Definition Multimedia Interface) ports (e.g., for connection to an external display), DisplayPort ports (e.g., for connection to an external display), audio ports, Ethernet ports, and / or Apple® Lightning® ports, wherein the purpose and function of each port are well known to those skilled in the art. The wired interfaces 780 of the computing device 702 provide a wired connection between the computing device 702 and a network 704, or a wired connection between the computing device 702 and one or more devices / peripherals (e.g., pointing devices, displays 754, speakers 752, cameras 736, physical keyboards 738, etc.) located outside the computing device 702. Power supply 782 is configured to supply power to each component of computing device 702, and can draw power from a battery inside computing device 702 and / or from a power cable inserted into a power port (e.g., USB port, A / C power port) of computing device 702. LI receiver 784 can be used for location determination of computing device 702, and may include a satellite navigation receiver, such as a Global Positioning System (GPS) receiver, or may include other types of location determiners, configured to determine the location of computing device 702 based on received information (e.g., using cellular base station triangulation positioning, etc.). Accelerometer 786 may be present to determine the orientation of computing device 702.

[0124] Note that the components illustrated in the computing device 702 are not essential, nor are they all included, and there may be a smaller or larger number of components, as those skilled in the art will recognize. For example, the computing device 702 may also include one or more of a gyroscope, barometer, proximity sensor, ambient light sensor, digital compass, etc. The processor 710 and memory 756 may coexist in the same semiconductor device package, such as being included together in an integrated circuit chip, FPGA, or system-on-a-chip (SoC), optionally included with other components of the computing device 702.

[0125] In an embodiment, computing device 702 is configured to implement any of the aforementioned features of the flowcharts herein. Computer program logic for performing any of the operations, steps, and / or functions described herein may be stored in storage device 720 and executed by processor 710.

[0126] In some embodiments, server infrastructure 770 may reside in computing environment 700 and be communicatively coupled to computing device 702 via network 704. When server infrastructure 770 is present, it may be a collection of network-accessible servers (e.g., a cloud-based environment or platform). Figure 7 As shown, server infrastructure 770 includes cluster 772. Each cluster in cluster 772 may include a group of one or more compute nodes and / or a group of one or more storage nodes. For example, as Figure 7 As shown, cluster 772 includes nodes 774. Each node of 774 is accessible via network 704 (e.g., in a "cloud-based" embodiment) for building, deploying, and managing applications and services. Any node of 774 can be a storage node, which includes multiple physical storage disks, SSDs, and / or other physical storage devices accessible via network 704 and configured to store data associated with the applications and services managed by node 774. For example, as... Figure 7 As shown, node 774 can store application data 778.

[0127] Each node of node 774 can function as a computing node, and node 774 includes one or more server computers, server systems, and / or computing devices. For example, node 774 may include one or more components of the computing device 702 disclosed herein. Each node of node 774 can be configured to execute one or more software applications (or "applications") and / or service and / or manage hardware resources (e.g., processors, memory, etc.) that can be used by users (e.g., clients) of a network-accessible server group. For example, as... Figure 7 As shown, node 774 can run application 776. In the implementation, the node in node 774 can run or include one or more virtual machines, each of which simulates a system architecture (e.g., an operating system) in an isolated manner, on which applications such as application 776 can be executed.

[0128] In embodiments, one or more clusters of cluster 772 may be located in the same location (e.g., within one or more nearby buildings with associated components such as backup power, redundant data communication systems, environmental control devices, etc.) to form a data center, or may be arranged in other ways. Therefore, in embodiments, one or more clusters of cluster 722 may be data centers within a distributed collection of data centers. In embodiments, exemplary computing environment 700 includes a cloud-based platform component, such as Amazon Web Services® from Amazon Web Services or Google Cloud Platform™ from Google, although these are merely examples and not intended to be limiting.

[0129] In this embodiment, computing device 702 may access application 776 in any manner to execute, such as through a client application and / or browser at computing device 702. Example browsers include Microsoft Edge® from Microsoft Corporation of Redmond, Washington; Mozilla Firefox® from Mozilla Corporation of Mountain View, California; Safari® from Apple Inc. of Cupertino, California; and Google® browser from Google Inc. of Mountain View, California.

[0130] For network (e.g., cloud) backup and data security purposes, computing device 702 may additionally and / or alternatively synchronize copies of application 714 and / or application data 716 to store them in network-based server infrastructure 770 as application 776 and / or application data 778. For example, operating system 712 and / or application 714 may include file hosting service clients such as Microsoft® OneDrive®, Amazon Web Services® Amazon Simple Storage Service (Amazon S3®), Dropbox®, Google Drive™, etc., which are configured to synchronize applications and / or data stored in storage device 720 of network-based server infrastructure 770.

[0131] In some embodiments, a local server 792 may reside within a computing environment 700 and may be communicatively coupled to a computing device 702 via a network 704. When a local server 792 is present, it is hosted within the organization's infrastructure and, in many cases, is actually located on-site at the organization's facilities. The local server 792 is controlled, managed, and maintained by the organization's IT (information technology) personnel or the organization's IT partners. Application data 798 may be shared by the local server 792 among the organization's computing devices, including computing device 702 (when it is part of the organization), via the organization's local network and / or other networks accessible to the organization, including the Internet. Furthermore, the local server 792 provides applications (such as application 796) to the organization's computing devices (including computing device 702). Therefore, the local server 792 may include a storage device 794 (which includes one or more physical storage devices, such as storage disks and / or SSDs) for storing application 796 and application data 798, and may include one or more processors for executing application 796. Furthermore, computing device 702 can be configured to synchronize copies of application 714 and / or application data 716 for use as backup storage of application 796 and / or application data 798 on local server 792.

[0132] The embodiments described herein can be implemented in one or more of computing device 702, network-based server infrastructure 770, and local server 792. For example, in some embodiments, computing device 702 can be used to implement a system, client, or device, or its components / subcomponents, disclosed elsewhere herein. In other embodiments, a combination of computing device 702, network-based server infrastructure 770, and / or local server 792 can be used to implement a system, client, or device, or its components / subcomponents, disclosed elsewhere herein.

[0133] As used herein, the terms “computer program medium,” “computer-readable medium,” and “computer-readable storage medium,” etc., refer to physical hardware media. Examples of such physical hardware media include any hard disk, optical disk, SSD, other physical hardware media (such as RAM, ROM, flash memory, digital video optical disk, compressed disk, MEM (microelectronic machine) memory, nanotechnology-based storage devices), and other types of physical / tangible hardware storage media of storage device 720. Such computer-readable media and / or storage media are distinct from and do not overlap with communication media and propagation signals (excluding communication media and propagation signals). Communication media include computer-readable instructions, data structures, program modules, or other data in the form of modulated data signals (such as carrier waves). The term “modulated data signal” refers to a signal having one or more characteristics that are set or altered to encode information in a manner that allows information to be encoded in the signal. For example, (but not limitingly), communication media include wireless media (such as acoustic waves, RF, infrared, and other wireless media) and wired media. Embodiments also relate to such communication media, which are separate from and do not overlap with embodiments relating to computer-readable storage media.

[0134] As described above, computer programs and modules (including application program 714) can be stored in storage device 720. Such computer programs can also be received on network 704 via wired interface(s) 780 and / or wireless interface(s) 760. When executed or loaded by an application, such computer programs enable computing device 702 to implement the features of the embodiments discussed herein. Therefore, such computer programs represent a controller for computing device 702.

[0135] The embodiments also relate to computer program products comprising computer code or instructions stored on any computer-readable medium or computer-readable storage medium. Such computer program products include physical storage of storage device 720 and other types of physical storage. IV. Additional Example Implementations

[0136] As described above, the systems and devices embodying the techniques described herein can be configured and supported in various ways to perform their respective functions, thereby supporting metadata and data modification concurrency in relational database systems. In embodiments, one or more steps or operations in any of the processes and / or flowcharts described herein may not be performed. Furthermore, other steps or operations may be performed, except for or in lieu of any of the steps or operations in any of the processes and / or flowcharts described herein. Further, in examples, one or more operations in any of the processes and / or flowcharts described herein may be performed out of order, in an alternative order, or partially (or completely) simultaneously with each other or concurrently with other operations.

[0137] As described herein, systems, devices, components, etc., configured to perform functions and / or operations in embodiments are also considered to perform those functions and / or operations.

[0138] The additional examples and embodiments described in this section may be applied to the examples disclosed in any other section or subsection of this disclosure.

[0139] This paper provides a relational database system. The relational database system includes: a metadata version-aware execution engine configured to: receive data read commands, the data read commands including a first query and a second query, each query referencing metadata objects in the metadata storage of the relational database system, and each query being configured to read user data objects from the user data storage of the relational database system; receive metadata modification commands to be executed concurrently with the data read commands, wherein the execution of the metadata modification commands modifies the metadata objects stored in the metadata storage of the relational database system; and, in response to receiving the data read commands, initiate a first transaction at time T1. The process involves: acquiring a metadata access lock from the lock manager of the relational database system; creating a first query plan for a first query, wherein the first query plan references a metadata object; using the metadata access lock, starting execution of the first query plan within the first transaction at time T2; completing the execution of the first query plan at time T3; and committing the first transaction at time T4; and in response to receiving a metadata modification command: starting a second transaction concurrently with the first transaction at time T5; acquiring a metadata change lock from the lock manager; modifying the metadata object within the second transaction using the metadata change lock, wherein the modification is not blocked by the metadata access lock; and committing the second transaction at time T6.

[0140] In another embodiment of the relational database system, time T2 is after time T1, time T5 is after time T2, time T3 is after time T5, and time T6 is after time T3.

[0141] In another embodiment of the relational database system, the metadata object includes a first version of the metadata object before executing the metadata modification command.

[0142] In another embodiment of the relational database system, executing a metadata modification command modifies a first version of a metadata object to a second version of the metadata object.

[0143] In another embodiment of the relational database system, the execution engine is configured to run in committed read snapshot isolation mode to: execute a second query within a first transaction before time T6, thereby compiling a second query plan, wherein the second query references a first version of the metadata object; and execute the second query again within the first transaction after time T6, thereby recompiling the second query plan to generate a third query plan, wherein the third query plan references a second version of the metadata object.

[0144] In another embodiment of the relational database system, the execution engine is configured to run in a normal snapshot isolation mode to: execute a second query within a first transaction before or after time T6, causing a second query plan to be compiled, wherein the second query plan references a first version of the metadata object; and execute the second query again within the first transaction after time T6, thereby reusing the second query plan, wherein the query plan references the first version of the metadata object.

[0145] In another embodiment of the relational database system, the relational database system further includes a transaction manager configured to determine which version of a first or second version of a metadata object is visible to a transaction at a predetermined time.

[0146] In another embodiment of the relational database system, the transaction manager is also configured to determine, at least in part, which version of the first or second version of the metadata object is visible to the transaction at a predetermined time, based on whether the execution engine is configured to operate in a first snapshot isolation mode, a second snapshot isolation mode, or a non-snapshot isolation mode.

[0147] This paper provides a method in a relational database system. The method includes: receiving a data read command, the data read command including a first query and a second query, each query referencing metadata objects in the metadata store of the relational database system, and each query being configured to read user data objects from the user data store of the relational database system; receiving a metadata modification command to be executed concurrently with the data read command, and wherein execution of the metadata modification command modifies the metadata objects; in response to receiving the data read command: at time T1, initiating a first transaction; acquiring a metadata access lock from the lock manager of the relational database system; creating a first query plan for the first query, wherein the first query plan references the metadata objects; using the metadata access lock, at time T2, starting execution of the first query plan within the first transaction; at time T3, completing the execution of the first query plan; and at time T4, committing the first transaction; and in response to receiving the metadata modification command: at time T5, initiating a second transaction concurrently with the first transaction; acquiring a metadata change lock from the lock manager; using the metadata change lock within the second transaction, wherein the modification is not blocked by the metadata access lock; and at time T6, committing the second transaction.

[0148] In another embodiment of the above method, time T2 is after time T1, time T5 is after time T2, time T3 is after time T5, and time T6 is after time T3.

[0149] In another embodiment of the above method, the metadata object includes a first version of the metadata object before executing the metadata modification command.

[0150] In another embodiment of the above method, executing a metadata modification command modifies the first version of the metadata object to a second version of the metadata object.

[0151] In another embodiment of the above method, the method further includes running the relational database system in a first snapshot isolation mode and: before time T6, executing a second query within a first transaction to compile a second query plan, wherein the second query plan references a first version of the metadata object; and after time T6, executing the second query again within the first transaction to recompile the second query plan to generate a third query plan, wherein the third query plan references a second version of the metadata object.

[0152] In another embodiment of the above method, the method further includes running the relational database system in a second snapshot isolation mode, and executing a second query within a first transaction before or after time T6, thereby compiling a second query plan, wherein the second query plan references a first version of the metadata object.

[0153] This document provides a computer program product including a computer-readable storage device on which computer program logic is recorded, which, when executed by at least one processor of a computing device, causes at least one processor to perform an operation. These operations include: receiving a data read command comprising a first query and a second query, each query referencing a metadata object in a metadata object in the metadata storage of the relational database system, and each query being configured to read a user data object from the user data store of the relational database system; receiving a metadata modification command to be executed concurrently with the data read command, wherein the execution of the metadata modification command modifies the metadata object; in response to receiving the data read command: at time T1, initiating a first transaction; acquiring a metadata access lock from the lock manager of the relational database system; creating a first query plan for the first query, wherein the first query plan references the metadata object; using the metadata access lock, at time T2, starting execution of the first query plan within the first transaction; at time T3, completing the execution of the first query plan; and at time T4, committing the first transaction; and in response to receiving the metadata modification command: at time T5, initiating a second transaction concurrently with the first transaction; acquiring a metadata change lock from the lock manager; using the metadata change lock within the second transaction, wherein the modification is not blocked by the metadata access lock; and at time T6, committing the second transaction.

[0154] In another embodiment of the aforementioned computer program product, time T2 is after time T1, time T5 is after time T2, time T3 is after time T5, and time T6 is after time T3.

[0155] In another embodiment of the aforementioned computer program product, the metadata object includes a first version of the metadata object before executing the metadata modification command.

[0156] In another embodiment of the aforementioned computer program product, executing a metadata modification command causes a first version of the metadata object to be modified to a second version of the metadata object.

[0157] In another embodiment of the aforementioned computer program product, the operation further includes running the relational database system in a first snapshot isolation mode and: before time T6, executing a second query within a first transaction to compile a second query plan, wherein the second query references a first version of the metadata object; and after time T6, executing the second query again within the first transaction to recompile the second query plan to generate a third query plan, wherein the third query plan references a second version of the metadata object.

[0158] In another embodiment of the aforementioned computer program product, the operation further includes running the relational database system in a second snapshot isolation mode, and executing a second query within a first transaction at a time before or after time T6, thereby compiling a second query plan, wherein the second query plan references a first version of the metadata object. V. Conclusion

[0159] References to "an embodiment," "an embodiment," "an exemplary embodiment," etc., in the specification indicate that the described embodiment may include specific features, structures, or characteristics, but not every embodiment may necessarily include such specific features, structures, or characteristics. Furthermore, such phrases do not necessarily refer to the same embodiment. Moreover, in describing specific features, structures, or characteristics of an embodiment, it is believed that those skilled in the art will recognize that such features, structures, or characteristics can be applied to other embodiments, whether or not explicitly described.

[0160] In this discussion, unless otherwise stated, adjectives modifying one or more features of an implementation of this disclosure as indicating conditions or relationships are limited to acceptable tolerances to ensure that the operation of the implementation conforms to its intended application. Furthermore, if this document describes the execution of an operation as "in response to" one or more factors, it should be understood that one or more factors can be considered as the sole contributing factor to the operation or as contributing factors that, together with one or more additional factors, cause the operation to occur, and that the operation can occur at or after the establishment of one or more factors. Moreover, where "based on" is used to indicate that an effect is a result of the indicated cause, it should be understood that the effect is not necessarily caused solely by the indicated cause, but may be caused by any number of possible additional causes. Therefore, as used herein, the term "based on" should be understood as equivalent to the term "at least based on".

[0161] Several example embodiments have been described above. No section / subsection heading provided herein is intended to be limiting. Embodiments are described herein, and embodiments of any type may be included in any section / subsection. Furthermore, any embodiment disclosed in any section / subsection may be combined in any manner with any other embodiment described in the same section / subsection and / or different sections / subsections.

[0162] In some example embodiments, one or more operations of the flowchart described herein may not be performed. Furthermore, other operations may be performed, in addition to or replacing the operations of the flowchart described herein. Further, in some example embodiments, one or more operations of the flowchart described herein may be performed out of order, in an alternative order, or partially (or completely) concurrently with each other or concurrently with other operations.

[0163] While various embodiments have been described above, it should be understood that these embodiments are presented by way of example only and are not intended to be limiting. Those skilled in the art will understand that various changes in form and detail may be made therein without departing from the spirit and scope of the embodiments. Therefore, the breadth and scope of the embodiments should not be limited to any of the foregoing exemplary embodiments, but should be defined only by the following claims and their equivalents.

Claims

1. A relational database system (100), comprising: The metadata version-aware execution engine (108) is configured as follows: Receive (502) data read commands (126, 308, 408), the data read commands (126, 308, 408) include a first query and a second query, each query referencing a metadata object in the metadata storage device (114) of the relational database system (100), and each query is configured to read a user data object from the user data storage of the relational database system (100); Receive (504) metadata modification commands (128, 302, 402) to be executed concurrently with the data read commands (126, 308, 408), and the execution of the metadata modification commands (128, 302, 402) causes the metadata object stored in the metadata storage device (114) of the relational database system (100) to be modified; In response to receiving the data read command (126, 308, 408) as stated in (506): At time T1, initiate the first transaction (512); Obtain (514) metadata access lock from the lock manager (124) of the relational database system (100); Create (516) a first query plan for the first query, wherein the first query plan references the metadata object; Using the metadata access lock, at time T2, within the first transaction, the execution of the first query plan begins (518); At time T3, the execution of the first query plan (520) is completed; as well as At time T4, commit the first transaction (522); and In response to receiving the metadata modification command (128, 302, 402) as stated in (508): At time T5, the second transaction (532) is started concurrently with the first transaction; Obtain (534) metadata from the lock manager (124) to change the lock; The metadata object is modified (536) within the second transaction using the metadata change lock, wherein the modification is not blocked by the metadata access lock; as well as At time T6, commit (538) the second transaction.

2. The relational database system according to claim 1, wherein time T2 is after time T1, time T5 is after time T2, time T3 is after time T5, and time T6 is after time T3.

3. The relational database system of claim 2, wherein the metadata object includes a first version of the metadata object before the metadata modification command is executed.

4. The relational database system according to claim 3, wherein executing the metadata modification command causes the first version of the metadata object to be modified to the second version of the metadata object.

5. The relational database system of claim 4, wherein the execution engine is configured to run in committed read snapshot isolation mode, so as to: Prior to T6, within the first transaction, the second query is executed, thereby compiling a second query plan, wherein the second query plan references the first version of the metadata object; and At a time after time T6, the second query is executed again within the first transaction, thereby recompiling the second query plan to generate a third query plan, wherein the third query plan references the second version of the metadata object.

6. The relational database system of claim 4, wherein the execution engine is configured to run in a normal snapshot isolation mode, so as to: Before or after time T6, within the first transaction, execute the second query to compile a second query plan, wherein the second query plan references the first version of the metadata object; and At a time after time T6, the second query is executed again within the first transaction, thereby reusing the second query plan, wherein the query plan references the first version of the metadata object.

7. The relational database system of claim 5, further comprising a transaction manager configured to determine which version of the metadata object, either the first version or the second version, is visible to a transaction at a predetermined time.

8. The relational database system of claim 7, wherein the transaction manager is further configured to determine, at least in part, which version of the metadata object, either the first or the second version, is visible to the transaction at a predetermined time, based on whether the execution engine is configured to operate in a first snapshot isolation mode, a second snapshot isolation mode, or a non-snapshot isolation mode.

9. A method (500) in a relational database system (100), the method comprising: Receive (502) data read commands (126, 308, 408), the data read commands (126, 308, 408) include a first query and a second query, each query referencing a metadata object in the metadata storage device (114) of the relational database system (100), and each query is configured to read a user data object from the user data storage of the relational database system (100); Receive (504) metadata modification commands (128, 302, 402) to be executed concurrently with the data read commands (126, 308, 408), and the execution of the metadata modification commands (128, 302, 402) causes the metadata object to be modified; In response to receiving the data read command (126, 308, 408) as stated in (506): At time T1, initiate the first transaction (512); Obtain (514) metadata access lock from the lock manager (124) of the relational database system (100); Create (516) a first query plan for the first query, wherein the first query plan references the metadata object; Using the metadata access lock, at time T2, within the first transaction, the execution of the first query plan begins (518); At time T3, the execution of the first query plan (520) is completed; as well as At time T4, commit the first transaction (522); and In response to receiving the metadata modification command (128, 302, 402) as stated in (508): At time T5, the second transaction (532) is started concurrently with the first transaction; Obtain (534) metadata from the lock manager (124) to change the lock; The metadata object is modified (536) within the second transaction using the metadata change lock, wherein the modification is not blocked by the metadata access lock; as well as At time T6, commit (538) the second transaction.

10. The method of claim 9, wherein time T2 is after time T1, time T5 is after time T2, time T3 is after time T5, and time T6 is after time T3.

11. The method of claim 10, wherein the metadata object includes a first version of the metadata object before the metadata modification command is executed.

12. The method of claim 11, wherein executing the metadata modification command causes the first version of the metadata object to be modified to a second version of the metadata object.

13. The method of claim 12, further comprising running the relational database system in a first snapshot isolation mode and: Prior to T6, within the first transaction, the second query is executed, thereby compiling a second query plan, wherein the second query plan references the first version of the metadata object; and At a time after time T6, the second query is executed again within the first transaction, thereby recompiling the second query plan to generate a third query plan, wherein the third query plan references the second version of the metadata object.

14. The method of claim 12, further comprising running the relational database system in a second snapshot isolation mode, and executing the second query within the first transaction at a time before or after time T6, thereby compiling a second query plan, wherein the second query plan references the first version of the metadata object.

15. A computer program product comprising a computer-readable storage device (720, 794) on which computer program logic (714, 776, 796) is recorded, the computer program logic (714, 776, 796) causing the at least one processor (710) of a computing device (702, 774, 792) to perform operations, the operations including: Receive (502) data read commands (126, 308, 408), the data read commands (126, 308, 408) include a first query and a second query, each query referencing a metadata object in a metadata object in a metadata storage device (114) of the relational database system (100), and each query is configured to read a user data object from the user data storage of the relational database system (100); Receive (504) metadata modification commands (128, 302, 402) to be executed concurrently with the data read commands (126, 308, 408), and the execution of the metadata modification commands (128, 302, 402) causes the metadata object to be modified; In response to receiving the data read command (126, 308, 408) as stated in (506): At time T1, initiate the first transaction (512); Obtain (514) metadata access lock from the lock manager (124) of the relational database system; Create (516) a first query plan for the first query, wherein the first query plan references the metadata object; Using the metadata access lock, at time T2, the execution of the first query plan (518) begins within the first transaction; At time T3, the execution of the first query plan (520) is completed; as well as At time T4, commit the first transaction (522); and In response to receiving the metadata modification command (128, 302, 402) as stated in (508): At time T5, the second transaction (532) is started concurrently with the first transaction; Obtain (534) metadata to change the lock; The metadata object is modified (536) within the second transaction using the metadata change lock, wherein the modification is not blocked by the metadata access lock; as well as At time T6, commit (538) the second transaction.

16. The computer program product of claim 15, wherein time T2 is after time T1, time T5 is after time T2, time T3 is after time T5, and time T6 is after time T3.

17. The computer program product of claim 16, wherein the metadata object includes a first version of the metadata object before the metadata modification command is executed.

18. The computer program product of claim 17, wherein executing the metadata modification command causes the first version of the metadata object to be modified to a second version of the metadata object.

19. The computer program product of claim 18, further comprising running the relational database system in a first snapshot isolation mode and: Prior to T6, within the first transaction, the second query is executed, thereby compiling a second query plan, wherein the second query plan references the first version of the metadata object; and At a time after time T6, the second query is executed again within the first transaction, thereby recompiling the second query plan to generate a third query plan, wherein the third query plan references the second version of the metadata object.

20. The computer program product of claim 18, further comprising running the relational database system in the second snapshot isolation mode, and executing the second query within the first transaction at a time before or after time T6, thereby compiling a second query plan, wherein the second query plan references the first version of the metadata object.

Images