Automatic query retry in a database environment

Abstract

Systems, methods and apparatus for automatically retrying queries. A method includes receiving a query for database data and assigning execution of the query to one or more execution nodes of a database platform. The method includes determining that execution of the query was unsuccessful. The method includes assigning a first retry execution of the query on a first version of the database platform, and assigning a second retry execution of the query on a second version of the database platform.

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application claims priority to U.S. patent application serial number 16 / 555,951 filed on August 29, 2019, the contents of which are hereby incorporated by reference in their entirety. Technical Field

[0003] The present disclosure relates to databases, and more particularly to automatic query retry in database systems.

[0004] background

[0005] A database is an organized collection of data that enables it to be easily accessed, manipulated, and updated. Databases are used as a method to store, manage, and retrieve information in an efficient manner. Traditional database management requires companies to provide infrastructure and resources to manage databases in data centers. The management of traditional databases can be very expensive and requires oversight by multiple people with a wide range of technical skills.

[0006] Databases are widely used for data storage and access in computing applications. The goal of database storage is to provide large amounts of information in an organized manner so that it can be accessed, managed, and updated. In a database, data can be organized into rows, columns, and tables. Different database storage systems can be used to store different types of content, such as bibliographic, full-text, digital, and / or image content. Furthermore, in computing, different database systems can be classified based on the organization method of the database. There are many different types of databases, including relational databases, distributed databases, cloud databases, object-oriented databases, and others.

[0007] Traditional relational database management systems (RDMS) require a lot of computing and storage resources and have limited scalability. Large amounts of data can be stored across multiple computing devices. Servers can manage data so that customers can access it using internal operations. For an entity that wants to have its own database server, the entity must spend a lot of resources on capital investment in hardware and infrastructure for the database and a lot of physical space for storing the database infrastructure. In addition, in the event of a power outage or other disaster, the database may be extremely vulnerable to data loss. Such traditional database systems have significant drawbacks that can be mitigated by cloud-based database systems.

[0008] Cloud database systems can be deployed and delivered through a cloud platform that allows organizations and end users to store, manage, and retrieve data from the cloud. Some cloud database systems include a traditional database architecture that is implemented by installing database software on top of a computing cloud. The database can be accessed through a web browser or application programming interface (API) for application and service integration. Some cloud database systems are operated by a vendor who directly manages the back-end processes of database installation, deployment, and resource allocation tasks on behalf of the customer. The client can have multiple end users who can access the database through a web browser and / or API. Cloud databases can provide significant benefits to some customers by mitigating the risk of losing database data and allowing multiple users across multiple geographic regions to access data.

[0009] Databases are used by various entities and companies to store information that may need to be accessed or analyzed. In an example, a retail company may store a list of all sales transactions in a database. The database may include information about when the transaction occurred, where the transaction occurred, the total cost of the transaction, identifiers and / or descriptions of all items purchased in the transaction, etc. The same retail company may also store, for example, employee information in the same database, which may include employee names, employee contact information, employee work history, employee compensation rates, etc. Depending on the needs of the retail company, employee information and transaction information may be stored in different tables in the same database. When a retail company wants to know the information stored in a database, it may need to "query" its database. The retail company may want to find data about, for example, the names of all employees who work in a specific store, the names of all employees who work on a specific date, all transactions made for a specific product within a specific time frame, and so on.

[0010] When a retail store wants to query its database to extract some organized information from the database, a query statement is executed against the database data. The query returns specific data based on one or more query predicates, which indicate what information the query should return. The query extracts specific data from the database and formats the data into a readable form. The query can be written in a language that the database understands, such as Structured Query Language ("SQL"), so that the database system can determine what data should be located and how the data should be returned. The query can request any relevant information stored within the database. If the appropriate data can be found to respond to the query, the database has the potential to reveal complex trends and activities. This power can only be exploited by using successfully executed queries.

[0011] In some cases, the execution of a query fails. Query execution can fail for a number of different reasons, including intermittent failures or software regressions. Intermittent failures can be caused by hardware failures, power outages, faulty electrical connections, temperature changes, vibrations, and more. Intermittent failures are difficult to predict and identify. Software regressions can be caused by bugs or errors in the software code. Software regressions can cause problems with continued query execution and should be identified and fixed. In some cases, it is desirable to retry a failed query so that a valid query response can be returned to the client.

[0012] In view of the foregoing, systems, methods and devices for automatic query retry in database systems are disclosed herein. The systems, methods and devices disclosed herein provide means for querying data, determining how and where queries should be retried, and analyzing query retries. BRIEF DESCRIPTION OF THE DRAWINGS

[0014] Non-limiting and non-exhaustive embodiments of the present disclosure are described with reference to the following drawings, wherein like reference numerals refer to the same or similar parts throughout the various views unless otherwise specified. The advantages of the present disclosure will be better understood with respect to the following description and drawings, wherein:

[0015] Figure 1 is a block diagram illustrating an example process flow for scheduling tasks on a database and separating internal and external tasks in a database platform;

[0016] Figure 2 is a block diagram illustrating a data processing platform;

[0017] Figure 3 is a block diagram illustrating a computing service manager;

[0018] Figure 4 is a block diagram illustrating an execution platform;

[0019] Figure 5 is a block diagram illustrating an example operating environment;

[0020] Figure 6 is a schematic diagram of the process flow for retrying failed queries;

[0021] Figure 7 It is a schematic diagram of the processing flow for query retry operation;

[0022] Figure 8 is a block diagram illustrating a resource manager;

[0023] Fig. 9 is a schematic flow chart of a method for retrying a failed query;

[0024] Fig.10 is a schematic flow chart of a method for determining whether a query failure is caused by regression or intermittent fault;

[0025] Fig.11 is a schematic flow chart of a method for retrying a failed query;

[0026] Fig.12 is a schematic flow chart of a method for generating and filtering a transaction log for query attempts in a database platform;

[0027] Fig.13 is a schematic flow chart of a method for retrying a failed query;

[0028] Fig.14 is a schematic flow chart of a method for retrying a failed query; and

[0029] Fig.15 is a schematic block diagram of an example computing device.

[0030] Detailed Description

[0031] Disclosed herein are systems, methods, and devices for automatic query retry in a database platform. The systems, methods, and devices of the present disclosure may be implemented to automatically retry failed queries and identify system errors based on query retry attempts. Embodiments of the present disclosure may be implemented to identify software regressions in a database platform. Additionally, embodiments of the present disclosure may be implemented to distinguish software regressions from intermittent failures.

[0032] In one embodiment of the present disclosure, a method can be implemented by a resource manager and / or a computing service manager of a database platform. The method includes: receiving a query for database data, and assigning the execution of the query to one or more execution nodes of the execution platform. One or more execution nodes can be configured to execute the query on a database platform of a first software version. The method includes determining that the execution of the query is unsuccessful. The method includes allocating a first retry execution of the query on a database platform of a first software version, and allocating a second retry execution of the query on a database platform of a second software version. The first and second retry executions of the query can be analyzed to determine whether the original failed execution of the query failed due to software regression or due to intermittent failure. In an embodiment, the query succeeds at most once, so that additional retry attempts are scheduled only after the previous retry attempt fails. In such an embodiment, if the first retry attempt succeeds, no additional retry attempts will be scheduled.

[0033] Databases are widely used for data storage and data access in computing applications. A database may include one or more tables that include or reference data that can be read, modified, or deleted using queries. However, for some modern data warehouse systems, executing queries may be unusually time and resource intensive because modern data warehouse systems typically include tables that store petabytes of data. Querying very large databases and / or tables may require scanning large amounts of data. Reducing the amount of data scanned for database queries is one of the main challenges in data organization and processing. When processing queries for very large amounts of data, it may be important to use materialized views to reduce the time and processing resources required to execute queries. The systems, methods, and devices disclosed herein provide a device for automatically retrying failed queries and performing analysis on query retry attempts.

[0034] In the following description, reference is made to the accompanying drawings which form a part thereof and in which are shown by way of illustration specific exemplary embodiments in which the present disclosure may be implemented. These embodiments are described in sufficient detail to enable those skilled in the art to practice the concepts disclosed herein, and it should be understood that the various disclosed embodiments may be modified and other embodiments may be utilized without departing from the scope of the present disclosure. Therefore, the following detailed description should not be considered limiting.

[0035] References throughout this specification to "one embodiment," "an embodiment," "an example," or "an example" mean that a particular feature, structure, or characteristic described in conjunction with the embodiment or example is included in at least one embodiment of the present disclosure. Thus, the phrases "in one embodiment," "in an embodiment," "an example," or "an example" appearing in various places throughout the specification do not necessarily all refer to the same embodiment or example. In addition, it should be understood that the drawings provided herewith are for explanation purposes to one of ordinary skill in the art and that the drawings are not necessarily drawn to scale.

[0036] According to the embodiments of the present disclosure, it can be embodied as an apparatus, method or computer program product. Therefore, the present disclosure can take the form of an embodiment consisting entirely of hardware, an embodiment consisting entirely of software (including firmware, resident software, microcode, etc.), or an embodiment combining software and hardware aspects, which can generally be referred to as "circuit", "module" or "system" in this article. In addition, the embodiments of the present disclosure can take the form of a computer program product embodied in any tangible expression medium, which has a computer-usable program code embodied in the medium.

[0037] Any combination of one or more computer-usable or computer-readable media may be utilized. For example, a computer-readable medium may include one or more of a portable computer floppy disk, a hard disk, a random access memory (RAM) device, a read-only memory (ROM) device, an erasable programmable read-only memory (EPROM or flash memory) device, a portable compact disk read-only memory (CDROM), an optical storage device, and a magnetic storage device. Computer program code for performing the operations of the present disclosure may be written in any combination of one or more programming languages. Such code may be compiled from source code into a computer-readable assembly language or machine code suitable for the device or computer on which the code will be executed.

[0038] Embodiments may also be implemented in a cloud computing environment. In this specification and the appended claims, "cloud computing" may be defined as a model for enabling universal, convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications, and services) that can be quickly configured via virtualization and released with minimal management effort or service provider interaction, and then expanded accordingly. Cloud models may consist of various features (e.g., on-demand self-service, broad network access, resource pools, rapid elasticity, and measurable services), service models (e.g., software as a service ("SaaS"), platform as a service ("PaaS"), and infrastructure as a service ("IaaS")), and deployment models (e.g., private cloud, community cloud, public cloud, and hybrid cloud).

[0039] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functions, and operations of possible implementations of the systems, methods, and computer program products according to various embodiments of the present disclosure. In this regard, each block in the flowchart or block diagram may represent a module, segment, or portion of a code, which includes one or more executable instructions for implementing one or more specified logical functions. It should also be noted that each block of the block diagram and / or flowchart and the combination of blocks in the block diagram and / or flowchart can be implemented by a dedicated hardware-based system or a combination of dedicated hardware and computer instructions that performs a specific function or action. These computer program instructions can also be stored in a computer-readable medium, which can instruct a computer or other programmable data processing device to function in a specific manner, so that the instructions stored in the computer-readable medium produce an article including an instruction device to implement the functions and / or actions specified in one or more blocks of the flowchart and / or block diagram.

[0040] The systems and methods described herein provide a flexible and scalable data warehouse using a new data processing platform. In some embodiments, the described systems and methods utilize a cloud infrastructure that supports cloud-based storage resources, computing resources, and the like. The example cloud-based storage resources provide a large amount of storage capacity available on demand at a low cost. In addition, these cloud-based storage resources can be fault-tolerant and highly scalable, which may be expensive to implement in private data storage systems. The example cloud-based computing resources are available on demand and can be priced based on the actual usage level of the resources. Typically, the cloud infrastructure is dynamically deployed, reconfigured, and deactivated in a rapid manner.

[0041] In the described systems and methods, the data storage system may utilize a relational database based on SQL (Structured Query Language). However, these systems and methods are applicable to any type of database and any type of data storage and retrieval platform, using any data storage architecture and using any language to store and retrieve data within the data storage and retrieval platform. The systems and methods described herein further provide a multi-tenant system that supports isolation of computing resources and data between different customers / clients and between different users within the same customer / client.

[0042] As used herein, the terms "comprising," "including," "comprising," "characterized by," and grammatical equivalents thereof are inclusive or open-ended terms that do not exclude additional, unrecited elements or method steps.

[0043] As used herein, a database table is a collection of records (rows). Each record contains a collection of values ​​for table attributes (columns). Database tables are typically physically stored in multiple smaller (variable or fixed size) storage units, such as files or blocks.

[0044] As used herein, a micro-partition is an immutable storage device in a database table that cannot be updated in-place and must be regenerated when the data stored therein is modified.

[0045] Some embodiments of the present disclosure may refer to "micro-partitions" stored as part of the data in a database table. The micro-partitions discussed herein may be considered as batch processing units, where each micro-partition has a continuous storage unit. For example, each micro-partition may contain between 50MB and 500MB of uncompressed data (note that the actual size in storage may be smaller because the data can be stored compressed). Groups of rows in a table may be mapped to separate micro-partitions organized in columns. This size and structure allows for extremely fine-grained selection of micro-partitions to be scanned, which may include millions or even hundreds of millions of micro-partitions. This granular selection process may be referred to herein as metadata-based "pruning". Pruning involves using metadata to determine which parts of a table (including which micro-partitions or micro-partition groupings in a table) are irrelevant to a query, then avoiding those irrelevant micro-partitions when responding to the query and scanning only relevant micro-partitions to respond to the query. Metadata about all rows stored in a micro-partition may be automatically collected, including: the value range of each column in the micro-partition; the number of different values; and / or other attributes for optimized and efficient query processing. In one embodiment, micro-partitioning may be automatically performed on all tables. For example, a table may be transparently partitioned using the order in which data is inserted / loaded. However, it should be understood that this disclosure of micro-partitioning is exemplary only and should be considered non-limiting. It should be understood that micro-partitioning may include other database storage devices without departing from the scope of this disclosure.

[0046] A detailed description of systems and methods consistent with various embodiments of the present disclosure is provided below. Although several embodiments are described, it should be understood that the present disclosure is not limited to any one embodiment, but includes many alternatives, modifications, and equivalents. In addition, although many specific details are set forth in the following description to provide a thorough understanding of the embodiments disclosed herein, some embodiments may be implemented without some or all of these details. In addition, for the sake of clarity, certain technical materials known in the prior art are not described in detail to avoid unnecessarily obscuring the present disclosure.

[0047] Now referring to the accompanying drawings, Figure 11 is a block diagram of an example embodiment of a process flow 100 for managing and executing query retry jobs on a database system and separating external and internal tasks in a database platform. In an embodiment, the process flow 100 is performed by a computing service manager 102 configured to manage and distribute query retry tasks and a resource manager 802 configured to manage and distribute the execution of queries received from client accounts. In the process flow 100, at 124, the resource manager 802 receives a query from a client account. The resource manager 802 references metadata to identify one or more files that are responsive to the query. At 126, the resource manager 802 distributes the processing of the one or more files to one or more execution nodes of the execution platform 116. At 128, the resource manager determines that the original execution of the query failed. If the original execution of the query failed due to an internal error rather than a non-internal "user error" based on the user's query text or data, then at 130, the resource manager 802 transfers the query to the computing service manager 102. Non-internal user errors may include errors in the structured query language (SQL) text of the query, which is based on the actual data being processed. In the process flow 100, the computing service manager 102 receives an indication of a failed query 104 at 106. In an embodiment, the computing service manager 102 receives the indication by receiving a query retry job in its queue. In an embodiment, the resource manager 802 transfers the query by placing the query in the queue of the computing service manager 102. The indication of the failed query 104 can be a positive / negative indication that only indicates that the query failed and does not provide additional information about why or when the query failed. The computing service manager 102 determines the tasks to be executed for the retry query at 108, and assigns these tasks to one or more execution nodes of one or more execution platforms 116 at 110. At 112, the computing service manager 102 analyzes the one or more query retry attempts.

[0048] Figures 1 to 3 The computing service manager 102 shown is a representation of a computing service instance. The computing service manager 102 can be one of multiple computing service instances serving a multi-tenant cloud-based database platform. In an embodiment, one or more computing service managers 102 are assigned to manage all "internal" tasks of a single client account. The computing service manager 102 can be assigned to manage the internal tasks of one or more client accounts. A client account can have multiple computing service managers 102 assigned to it. Multiple computing service instances are configured to jointly manage the execution of internal database tasks that are not directly received from client accounts. Such internal tasks include, for example, retrying failed queries, refreshing materialized views, refreshing table aggregations, clustering tables, and the like.

[0049] The compute service manager 102 may work in conjunction with one or more resource managers 802. In an embodiment, there is a resource manager 802 for each compute service manager across database platforms. In an embodiment, the number of resource managers 802 and the number of compute service managers 102 are not equal. Resource managers 802 are similar to compute service managers 102, except that resource managers 802 are configured to manage the execution of "external" database tasks received from client accounts. Such external tasks may include, for example, query requests received from clients, requests to generate materialized views, requests to compute aggregates, and the like. Figure 3 As shown, the resource manager may include each component associated with the computing service manager 102, and may include additional components as needed. The computing service manager 102 and the resource manager 802 may work together and may transfer work between each other. For example, a query request may originate from a client account and be received by the resource manager 802. If the execution of the query fails, the query retry attempt may be transferred from the resource manager 802 to the computing service manager 102. On the entire database platform, different computing service managers 102 and resource managers 802 may run different software versions of the database platform at the same time.

[0050] As discussed herein, the term "database query manager" may generally refer to either the computing service manager 102 and / or the resource manager 802. The computing service manager 102 and the resource manager 802 have similar components and may perform similar tasks and may be interchangeable in certain circumstances and / or may be specifically assigned to certain tasks, certain clients, certain portions of database data, and the like.

[0051] At 108, the computing service manager 102 can determine the task for retrying the query by many different methods. The computing service manager 102 can receive the following instructions from the client or system administrator: the query should be retried by a specific execution platform for a certain computing service instance, a specific version of software for a database platform, etc. Alternatively, the computing service manager 102 can make these determinations using the query retry module 114. At 118, the query retry module 114 can select a computing service instance for identifying and assigning tasks for retrying the query. At 120, the query retry module 114 can select the version of the database platform on which the query should be retried. The query retry module 114 can select an execution platform 122 for retrying the query.

[0052] In an embodiment, the computing service manager 102 schedules and manages the execution of query retries on behalf of a client account. The computing service manager 102 can schedule any SQL query. The computing service manager 102 can play the role of scheduling failed queries 104 as if it were a client account rather than an internal account or other special account. The computing service manager 102 can embody, for example, the role of an account administrator or a role with the minimum scope required to complete the retry of a failed query 104.

[0053] In an embodiment, the computing service manager 102 determines the tasks for retrying the query at 108 and assigns these tasks at 110. The computing service manager 102 can generate one or more discrete work units that can be referred to as tasks. The task includes, for example, a task type, a task identifier, an account identifier, a payload that can be converted into one or more discrete tasks, and a set of options (e.g., indicating the number of retries) that control how to retry the failed query 104. In an embodiment, the computing service manager 102 identifies one or more micro-partitions of data that need to be read to retry the query. The computing service manager 102 can form a batch of micro-partitions that need to be read to retry the query, and can assign one or more batches to different execution nodes of the execution platform 116. The computing service manager 102 can determine how many times the query should be retried, and whether the query should be retried for different computing service instances or different versions of the software of the database platform. The computing service manager 102 can further determine whether the query should be retried on different execution nodes or execution platforms. The computing service manager 102 can determine how many times the query should be retried and where the query should be retried based on the cause of the original failure of the query. If the cause of the original failure for the query is unknown, the computing service manager 102 can determine how many times and where the query should be retried to attempt to identify the cause of the original execution failure of the query.

[0054] The computing service manager 102 may assign a task 110 to retry the query. In an embodiment, the computing service manager 102 identifies multiple micro-partitions of data that need to be read to retry the query, and assigns each of the multiple micro-partitions to one or more execution nodes of the execution platform 116. The computing service manager 102 may assign tasks based on the storage and processing availability of multiple execution nodes of the execution platform. The computing service manager 102 may assign tasks to attempt to identify the cause of the original execution failure of the query. For example, the computing service manager 102 may assign the query retry to the same one or more execution nodes that originally attempted to execute the query. The computing service manager 102 may assign the query retry to a new execution node that did not participate in the original failed execution of the query.

[0055] At 112, the computing service manager 102 analyzes the query retry attempt to identify the reason for the query failure. The computing service manager 102 can determine that the query failed due to an intermittent failure. Database queries may fail due to many different intermittent failures, which may be caused by electrical problems, circuit problems, temperature changes, vibrations, voltage problems, power outages, etc. In an embodiment, the computing service manager 102 can determine that the query failed due to an intermittent failure, but may not be able to identify the cause of the intermittent failure. In an example, the computing service manager 102 can retry the query using the same computing service instance, the same execution node, and the same database platform version as the original execution attempt for the query. If the query retry succeeds without changing any of the computing service instance, execution node, or database platform version, the computing service manager 102 can infer that the original execution of the query failed due to an intermittent failure.

[0056] Alternatively, the computing service manager 102 may determine that the query failed due to a system problem such as a program error or error in the software or firmware of the database platform. The computing service manager 102 may run the query on the same database platform version as the original run of the failed query (i.e., the same software and code as the database platform). The computing service manager 102 may additionally run the query on other versions of the database platform. The computing service manager 102 may determine that the query failed due to a system error based on the results of multiple query retries. For example, if a query retry on the same version of the database platform fails again, and a query retry on another version of the database platform is successfully executed, the computing service manager 102 may infer that the software of the database platform has an error in the version used for the original execution of the query.

[0057] In an embodiment, the computing service manager 102 generates a report indicating when failed queries 104 are scheduled to be retried and the estimated amount of computing resources busy retrying failed queries 104. The computing service manager 102 can generate a statement for each task that exposes the failed queries 104 to applicable client accounts through a filter. The computing service manager 102 can alert the client account when a failed query 104 is being retried.

[0058] At 118, the query retry module 114 may select a computing service instance to manage the query retry. In an embodiment, the computing service manager 102 is one of a plurality of computing service managers serving a multi-tenant cloud-based database platform. The query retry module 114 may be incorporated into the same computing service manager 102 that manages the original failed execution of the query. The query retry module 114 may determine that the query retry should be performed by the same computing service manager 102 and / or by one or more different computing service instances. In an embodiment, multiple computing service instances across the database platform run software for different versions of the database platform at any given time. For example, a new version of software for the database platform may be launched on a selected number of computing service instances, while other computing service instances continue to run older versions of the software. This gradual rollout may help identify any errors or program errors in the newly launched software. The query retry module 114 may determine that the query should be retried multiple times by a plurality of different computing service instances. The query retry module 114 may make this determination to identify whether the original execution of the query failed due to an intermittent failure or a repeated system error.

[0059] In an embodiment, the query retry module 114 selects a computing service instance to manage query retries based on the availability of multiple computing service instances across the database platform. In an embodiment, the original failed execution of the query is managed by a resource manager, which handles "external" jobs received from client accounts, such as queries requested by clients. Then, the retry of the query can be handled by a computing service manager, which handles "internal" jobs that are not client-facing. Internal jobs include, for example, query retries, refreshing materialized views, performing adaptive aggregation of database data, updating metadata, and the like. In various embodiments, Figure 1 The illustrated query retry module 114 may be incorporated into a resource manager and / or a computing service manager and may be associated with the same resource manager and / or computing service manager that oversees failed executions of queries.

[0060] At 120, the query retry module 114 can select the version of the database platform on which the query retry should be performed. In an embodiment, the system, method, and device disclosed herein are part of a multi-tenant cloud-based database platform. The database platform can have multiple resource managers (for performing external jobs) and multiple computing service managers (for performing internal jobs). Each of the multiple resource managers and multiple computing service managers can operate under different versions of the software for the database platform. In an embodiment, when a new version of the software for the database platform is launched, the new version is only installed in a selected number of resource managers and / or computing service managers. The remaining resource managers and / or computing service managers can continue to run the older version of the software for the database platform. The query retry module 114 can select one of the multiple available versions of the software for running the query retry.

[0061] In an embodiment, the query retry module 114 determines that the query should be retried on the same version of software as the original failed execution attempt. The query retry module 114 may determine that the query should be additionally retried on one or more other versions of the software. The results of these multiple retry attempts may be analyzed to determine whether the original failed execution of the query was due to an intermittent failure or a system error.

[0062] At 122, the query retry module 114 may select one or more execution nodes or execution platforms to perform one or more retry attempts. The query retry module 114 may select execution resources based on storage and / or processing availability and / or current workload. The query retry module 114 may select the same execution resources that attempted to execute the original failed execution of the query because those execution resources may have cached certain portions of the data in response to the query. The query retry module 114 may select the same execution resources that attempted to execute the original failed execution of the query in an effort to identify whether the original execution of the query failed due to an intermittent failure or due to a system error. In an embodiment, there is no central query retry module 114 that determines the execution resources for multiple retry attempts, but rather each individual computing service instance that is assigned the task of performing a query retry makes these determinations.

[0063] In an embodiment, the query retry module 114 selects one or more execution nodes to perform one or more retry attempts on the query. The query retry module 114 may determine that different execution nodes will be used to retry the query multiple times. The first retry execution of the query may be performed on the same execution node that attempted the original failed execution of the query. The second retry execution of the query may be performed on a different execution node that did not attempt the original failed execution of the query. The third retry execution of the query may be performed by a mixture of execution nodes that have attempted and have not attempted the original failed execution of the query. The query retry module 114 may schedule multiple retries of the query until the query succeeds and / or the cause of the original failure of the query has been identified. For example, it may be determined that the original failure of the query was caused by a hardware problem or a problem with a specific server involved in the original execution of the query. This determination may be made by performing multiple retries of the query using multiple different execution nodes.

[0064] In an embodiment, the query retry module 114 determines at 122 that the query should be retried on the same execution node that attempted to execute the original failed execution of the query. The results of this retry attempt can be analyzed to determine if there is a hardware problem with a particular server. If the query retry fails on the same execution node for the original failed execution of the query, this may indicate that further investigation should be conducted to determine if there is a problem with the server running those one or more execution nodes.

[0065] In an embodiment, the query retry module 114 first selects one or more versions of a database platform to perform one or more query retries at 120. Then, the query retry module 114 may select one or more computing service instances to manage the one or more query retries at 118. The query retry module 114 may select a computing service instance based on the version of the database platform that the computing service instance is currently running.

[0066] The query retry module 114 may be incorporated into Figure 1 102. Alternatively, the query retry module 114 can be separate from any computing service instance and can be configured to make determinations about query retry attempts for one or more accounts of the multi-tenant database platform. A separate instance of the query retry module 114 can be incorporated into each computing service instance. A single instance of the query retry module 114 can be incorporated into a single computing service instance and can make determinations about query retry attempts for one or more accounts of the multi-tenant database platform.

[0067] Without departing from the scope of this disclosure, Figure 1100 in the process flow 100. For example, the determination made by the query retry module 114 can be made by the computing service manager 102 that received the query retry job in its queue. The determination made by the query retry module 114 can be made by the resource manager that managed the original failed execution of the query. The determination made by the query retry module 114 can be made by some other resource manager 802 and / or the computing service manager 102.

[0068] In an embodiment, the resource manager 802 that manages the original failed execution of the query further determines whether the query can be retried, whether the query should be retried, where the query should be retried, on which version of the database platform the query should be retried, and which computing service manager should manage the retry of the query. The resource manager 802 can transfer the query to the appropriate computing service manager based on these determinations. In an embodiment, the computing service manager that oversees the retry attempts of the query can generate additional retry attempts based on whether the retry attempts are successful or unsuccessful. In an embodiment, the resource manager 802 that manages the original failed execution of the query can transfer the query to multiple different computing service managers to retry the query multiple times. The resource manager 802 can determine that the query should be retried on multiple versions of the database platform, on multiple different execution nodes, and by multiple computing service managers and / or resource managers.

[0069] In an embodiment, the transaction log is stored in a metadata store and / or in one or more of a plurality of shared storage devices in a database platform. The transaction log may include a list of all jobs that have been executed for a client account. The transaction log may include a list of each query retry attempt for a single query. In an embodiment, a client account may request a transaction log, and a filtered transaction log may be generated that omits query retry attempts and includes only the original execution of the query and / or an indication of a successful retry attempt of the query. The filtered transaction log may be provided to the client account. In an embodiment, the transaction log includes a list of all "external" jobs executed based on a direct request from a client account, and omits all "internal" jobs that are not received from the client account to improve the performance of the database platform. In an embodiment, a client account may request a dedicated transaction log that includes a list of all external and / or internal jobs that the client account wishes to see. In an embodiment, a transaction log is generated that includes a list of all attempts to execute a single query, all queries over a period of time, all queries for specific database data, and the like.

[0070] Figure 2 2 is a block diagram depicting an example embodiment of a data processing platform 200. Figure 2As shown, the computing service manager 102 communicates with the queue 204, the client account 208, the metadata 206, and the execution platform 116. In an embodiment, the computing service manager 102 does not receive any direct communications from the client account 208, but only receives communications about jobs from the queue 204. The jobs in the queue 204 may include, for example, retrying failed queries, refreshing materialized views, refreshing aggregations, clustering tables, etc. In particular embodiments, the computing service manager 102 can support any number of client accounts 208, such as end users providing data storage and retrieval requests, system administrators managing the systems and methods described herein, and other components / devices that interact with the computing service manager 102. As used herein, the computing service manager 102 may also be referred to as a "global service system" that performs the various functions discussed herein.

[0071] The computing service manager 102 communicates with the queue 204. The queue 204 can provide a job to the computing service manager 102 in response to a triggering event. In an embodiment, the triggering event is a failed query, and the job is a retry of the failed query. In an embodiment, the resource manager 802 that manages the original failed execution of the query is configured to enter a job in the queue 204 indicating that the computing service manager 102 should retry the query. This separation of external tasks (e.g., queries received from client accounts) and internal tasks (e.g., retrying queries) can ensure that the resource manager 802 is available to receive client requests and that the internal tasks do not occupy processing resources while the external tasks are waiting. One or more jobs can be stored in the queue 204 in a received order and / or priority order, and each of these one or more jobs can be transmitted to the computing service manager 102 for scheduling and execution. The queue 204 may determine jobs to be executed based on triggering events such as failure of a query, ingestion of data, deletion of one or more rows in a table, update of one or more rows in a table, a materialized view being out of date with respect to its source table, a table reaching a predefined clustering threshold indicating that the table should be re-clustered, etc. The queue 204 may determine internal jobs that should be executed to improve the performance of the database and / or improve the organization of the database data. In an embodiment, the queue 204 does not store queries to be executed for client accounts, but only includes database jobs that improve database performance.

[0072] The computing service manager 102 is also coupled to metadata 206, which is associated with all data stored throughout the data processing platform 200. In some embodiments, the metadata 206 includes a summary of the data stored in the remote data storage system and the data available from the local cache. In addition, the metadata 206 may include information about how the data is organized in the remote data storage system and the local cache. The metadata 206 allows systems and services to determine whether a data segment needs to be accessed without having to load or access the actual data from the storage device.

[0073] In an embodiment, the computing service manager 102 and / or the queue 204 may determine that a job should be executed based on the metadata 206. In such an embodiment, the computing service manager 102 and / or the queue 204 may scan the metadata 206 and determine that a job should be executed to improve data organization or database performance.

[0074] The computing service manager 102 can receive rules or parameters from the client account 208, and such rules or parameters can guide the computing service manager 102 to schedule and manage internal jobs. The client account 208 can indicate that the internal job should only be executed at a specific time or should only utilize the processing resources set to the maximum amount. The client account 208 can further indicate that the computing service manager 102 should be prompted to determine one or more triggering events that the job should be executed. The client account 208 can provide parameters about how many times a task can be re-executed and / or when the task should be re-executed. In an embodiment, the computing service manager 102 is configured to give a higher priority to query retries than other internal tasks.

[0075] The computing service manager 102 is further coupled to an execution platform 116, which provides a plurality of computing resources for performing various data storage and data retrieval tasks, as discussed in more detail below. The execution platform 116 is coupled to a plurality of data storage devices 212a, 212b, and 212n that are part of the storage platform 210. Although in Figure 2 1, the execution platform 116 can communicate with any number of data storage devices. In some embodiments, the data storage devices 212a, 212b, and 212n are cloud-based storage devices located in one or more geographic locations. For example, the data storage devices 212a, 212b, and 212n can be part of a public cloud infrastructure or a private cloud infrastructure. The data storage devices 212a, 212b, and 212n can be hard disk drives (HDDs), solid-state drives (SSDs), storage clusters, Amazon S3 TMStorage system or any other data storage technology. In addition, the storage platform 210 may include a distributed file system (such as Hadoop Distributed File System (HDFS)), an object storage system, and the like.

[0076] In certain embodiments, the communication links between the computing service manager 102, the queue 204, the metadata 206, the client account 208 and the execution platform 116 are implemented via one or more data communication networks. Similarly, the communication links between the execution platform 116 and the data storage devices 212a-212n in the storage platform 210 are implemented via one or more data communication networks. These data communication networks can utilize any communication protocol and any type of communication medium. In some embodiments, the data communication network is a combination of two or more data communication networks (or sub-networks) coupled to each other. In alternative embodiments, these communication links are implemented using any type of communication medium and any communication protocol.

[0077] like Figure 2 As shown, data storage devices 212a, 212b, and 212n are separated from the computing resources associated with execution platform 116. The architecture supports dynamic changes to data processing platform 200 based on changing data storage / retrieval needs and changing needs of users and systems accessing data processing platform 200. Support for dynamic changes allows data processing platform 200 to scale rapidly in response to changing needs for systems and components within data processing platform 200. The separation of computing resources from data storage devices supports the storage of large amounts of data without requiring a correspondingly large amount of computing resources. Similarly, this separation of resources supports a significant increase in computing resources used at a particular time without a corresponding increase in available data storage resources.

[0078] The computing service manager 102, queues 204, metadata 206, client accounts 208, execution platform 116, and storage platform 210 are in Figure 2 204, metadata 206, client accounts 208, execution platform 116, and storage platform 210. However, each of computing service manager 102, queue 204, metadata 206, client accounts 208, execution platform 116, and storage platform 210 can be implemented as a distributed system (e.g., multiple systems / platforms distributed at multiple geographical locations). In addition, each of computing service manager 102, metadata 206, execution platform 116, and storage platform 210 can be expanded or reduced (independently of each other) based on changes to requests received from queue 204 and / or client accounts 208 and changing needs of data processing platform 200. Therefore, in the described embodiment, data processing platform 200 is dynamic and supports regular changes to meet current data processing needs.

[0079] During typical operation, the data processing platform 200 processes a plurality of jobs received from the queue 204 or determined by the computing service manager 102. These jobs are scheduled and managed by the computing service manager 102 to determine when and how to execute the job. For example, the computing service manager 102 may divide the job into a plurality of discrete tasks, and may determine what data is needed to execute each of the plurality of discrete tasks. The computing service manager 102 may assign each of the plurality of discrete tasks to one or more nodes of the execution platform 116 to process the task. The computing service manager 102 may determine what data is needed to process the task, and further determine which nodes within the execution platform 116 are best suited to process the task. Some nodes may have cached the data required to process the task, and therefore are good candidates for processing the task. The metadata 206 assists the computing service manager 102 in determining which nodes in the execution platform 116 have cached at least a portion of the data required to process the task. One or more nodes in the execution platform 116 use the data cached by the node and the data retrieved from the storage platform 210 when necessary to process the task. It is desirable to retrieve as much data as possible from the cache within the execution platform 116 because the retrieval speed is generally much faster than retrieving data from the storage platform 210 .

[0080] like Figure 2 As shown, the data processing platform 200 separates the execution platform 116 from the storage platform 210. In this arrangement, the processing resources and cache resources in the execution platform 116 operate independently of the data storage resources 212a-212n in the storage platform 210. Therefore, the computing resources and cache resources are not limited to specific data storage resources 212a-212n. Instead, all computing resources and all cache resources can retrieve data from and store data in any data storage resource in the storage platform 210. In addition, the data processing platform 200 supports adding new computing resources and cache resources to the execution platform 116 without making any changes to the storage platform 210. Similarly, the data processing platform 200 supports adding data storage resources to the storage platform 210 without making any changes to the nodes in the execution platform 116.

[0081] Figure 3 is a block diagram depicting an embodiment of a computing service manager 102. Figure 3As shown, the computing service manager 102 includes an access manager 302 and a key manager 304 coupled to a data storage device 306. The access manager 302 handles authentication and authorization tasks for the system described herein. The key manager 304 manages the storage and authentication of keys used during authentication and authorization tasks. For example, the access manager 302 and the key manager 304 manage keys for accessing data stored in remote storage devices (e.g., data storage devices in the storage platform 210). As used herein, remote storage devices may also be referred to as "permanent storage devices" or "shared storage devices." The request processing service 308 manages received data storage requests and data retrieval requests (e.g., jobs to be executed on database data). For example, the request processing service 308 may determine the data necessary to process a received data storage request or data retrieval request. The necessary data may be stored in a cache within the execution platform 116 (as discussed in more detail below), or may be stored in a data storage device in the storage platform 210. The management console service 310 supports administrators and other system managers access to various systems and processes. Additionally, management console service 310 may receive requests to execute jobs and monitor workload on the system.

[0082] The computing service manager 102 also includes a job compiler 312, a job optimizer 314, and a job executor 310. The job compiler 312 parses the job into multiple discrete tasks and generates execution code for each of the multiple discrete tasks. The job optimizer 314 determines the best method to execute the multiple discrete tasks based on the data that needs to be processed. The job optimizer 314 also handles various data pruning operations and other data optimization techniques to improve the speed and efficiency of executing the job. The job executor 316 executes the execution code of the job received from the queue 204 or determined by the computing service manager 102.

[0083] The job scheduler and coordinator 318 sends the received jobs to the appropriate service or system for compilation, optimization and dispatch to the execution platform 116. For example, the jobs can be prioritized and processed in this priority order. In an embodiment, the job scheduler and coordinator 318 determines the priority of internal jobs scheduled by the computing service manager 102 and other "external" jobs (such as user queries that can be scheduled by other systems in the database but can utilize the same processing resources in the execution platform 116). In some embodiments, the job scheduler and coordinator 318 identifies or assigns specific nodes in the execution platform 116 to process specific tasks. The virtual warehouse manager 320 manages the operation of multiple virtual warehouses implemented in the execution platform 116. As described below, each virtual warehouse includes multiple execution nodes, each execution node includes a cache and a processor.

[0084] In addition, the computing service manager 102 includes a configuration and metadata manager 322 that manages information related to data stored in remote data storage devices and in local caches (i.e., caches in the execution platform 116). As discussed in more detail below, the configuration and metadata manager 322 uses metadata to determine which data files need to be accessed to retrieve data for processing a particular task or job. The monitor and workload analyzer 324 oversees the processes executed by the computing service manager 102 and manages the distribution of tasks (e.g., workloads) across virtual warehouses and execution nodes in the execution platform 116. The monitor and workload analyzer 324 also reallocates tasks as needed based on the changing workload on the entire data processing platform 200 and further reallocates tasks based on user (i.e., "external") query workloads that may also be processed by the execution platform 116. The configuration and metadata manager 322 and the monitor and workload analyzer 324 are coupled to the data storage device 326. Figure 3 Data storage devices 306 and 326 in represent any data storage devices within data processing platform 200. For example, data storage devices 306 and 326 may represent caches in execution platform 116, storage devices in storage platform 210, or any other storage devices.

[0085] The computing service manager 102 also includes a transaction management and access control module 328, which manages various tasks and other activities associated with the processing of data storage requests and data access requests. For example, the transaction management and access control module 328 provides consistent and synchronized access to data by multiple users or systems. Since multiple users / systems can access the same data at the same time, changes to the data must be synchronized to ensure that each user / system works with the current version of the data. The transaction management and access control module 328 provides control over various data processing activities at a single centralized location in the computing service manager 102. In some embodiments, the transaction management and access control module 328 interacts with the job executor 316 to support the management of various tasks being performed by the job executor 316.

[0086] Figure 4 is a block diagram depicting an embodiment of the execution platform 116. Figure 4As shown, the execution platform 116 includes multiple virtual warehouses, including virtual warehouse 1, virtual warehouse 2 and virtual warehouse n. Each virtual warehouse includes multiple execution nodes, and each execution node includes a data cache and a processor. The virtual warehouse can execute multiple tasks in parallel by using multiple execution nodes. As discussed herein, the execution platform 116 can add new virtual warehouses and discard existing virtual warehouses in real time based on the current processing needs of the system and users. This flexibility allows the execution platform 116 to quickly deploy a large amount of computing resources when needed, without having to continue to pay for those computing resources when they are no longer needed. All virtual warehouses can access data in any data storage device (e.g., any storage device in the storage platform 210).

[0087] although Figure 4 Each virtual warehouse shown in includes three execution nodes, but a particular virtual warehouse may include any number of execution nodes. In addition, the number of execution nodes in a virtual warehouse is dynamic, so that new execution nodes are created when there is additional demand, and existing execution nodes are deleted when they are no longer needed.

[0088] Each virtual warehouse has access to Figure 3 Thus, a virtual warehouse need not be assigned to a specific data storage device 212a-212n, but can access data in any data storage device 212a-212n within the storage platform 210. Similarly, Figure 4 Each execution node shown in can access data from any data storage device 212a-212n. In some embodiments, a specific virtual warehouse or a specific execution node can be temporarily assigned to a specific data storage device, but the virtual warehouse or execution node can later access data in any other data storage device.

[0089] exist Figure 4 In the example of , virtual warehouse 1 includes three execution nodes 402a, 402b and 402n. Execution node 402a includes cache 404a and processor 406a. Execution node 402b includes cache 404b and processor 406b. Execution node 402n includes cache 404n and processor 406n. Each execution node 402a, 402b and 402n is associated with processing one or more data storage and / or data retrieval tasks. For example, a virtual warehouse can handle data storage and data retrieval tasks associated with internal services (such as clustering services, instantiated view refresh services, file compression services, stored procedure services, or file upgrade services). In other embodiments, a specific virtual warehouse can handle data storage and data retrieval tasks associated with a specific data storage system or a specific category of data.

[0090] Similar to the virtual warehouse 1 discussed above, virtual warehouse 2 includes three execution nodes 412a, 412b and 412n. Execution node 412a includes cache 414a and processor 416a. Execution node 412b includes cache 414b and processor 416b. Execution node 412n includes cache 414n and processor 416n. In addition, virtual warehouse 3 includes three execution nodes 422a, 422b and 422n. Execution node 422a includes cache 424a and processor 426a. Execution node 422b includes cache 424b and processor 426b. Execution node 422n includes cache 424n and processor 426n.

[0091] In some embodiments, with respect to data being cached by the execution node, Figure 4 The execution nodes shown are stateless. For example, these execution nodes do not store or otherwise maintain state information about the execution nodes or data cached by a particular execution node. Therefore, in the event of an execution node failure, the failed node can be transparently replaced with another node. Since there is no state information associated with the failed execution node, a new (replacement) execution node can easily replace the failed node without having to worry about recreating specific state.

[0092] although Figure 4 The execution nodes shown each include a data cache and a processor, but alternative embodiments may include execution nodes that include any number of processors and any number of caches. In addition, the size of the cache may vary between different execution nodes. Figure 4 The cache shown in stores data retrieved from one or more data storage devices in the storage platform 210 in a local execution node. Therefore, the cache reduces or eliminates the bottleneck problem that occurs in a platform that continuously retrieves data from a remote storage system. Instead of repeatedly accessing data from a remote storage device, the systems and methods described herein access data from a cache in an execution node, which is significantly faster and avoids the bottleneck problem discussed above. In some embodiments, the cache is implemented using a high-speed storage device that provides fast access to cached data. Each cache can store data from any storage device in the storage platform 210.

[0093] In addition, cache resources and computing resources can vary between different execution nodes. For example, an execution node can include a large amount of computing resources and a minimum of cache resources, so that the execution node can be used for tasks that require a large amount of computing resources. Another execution node can include a large amount of cache resources and a minimum of computing resources, so that the execution node can be used for tasks that require a large amount of data to be cached. Another execution node can include cache resources that provide faster input-output operations, which is useful for tasks that require rapid scanning of large amounts of data. In some embodiments, based on the expected tasks that the execution node will perform, the cache resources and computing resources associated with a specific execution node are determined when the execution node is created.

[0094] In addition, the cache resources and computing resources associated with a particular execution node may change over time based on the changing tasks performed by the execution node. For example, if the tasks performed by the execution node become processor intensive, more processing resources may be allocated to the execution node. Similarly, if the tasks performed by the execution node require a larger cache capacity, more cache resources may be allocated to the execution node.

[0095] Although virtual warehouses 1, 2, and n are associated with the same execution platform 116, multiple computing systems at multiple geographic locations may be used to implement the virtual warehouses. For example, virtual warehouse 1 may be implemented by a computing system at a first geographic location, while virtual warehouses 2 and n may be implemented by another computing system at a second geographic location. In some embodiments, these different computing systems are cloud-based computing systems maintained by one or more different entities.

[0096] In addition, each virtual warehouse Figure 4 402a and 402b are shown as having multiple execution nodes. Multiple computing systems located at multiple geographic locations can be used to implement multiple execution nodes associated with each virtual warehouse. For example, an instance of virtual warehouse 1 implements execution nodes 402a and 402b on a computing platform at one geographic location, and implements execution node 402n at a different computing platform at another geographic location. The selection of a particular computing system to implement an execution node can depend on various factors, such as the resource level required for a particular execution node (e.g., processing resource requirements and cache requirements), the resources available at a particular computing system, the communication capabilities of a network within or between geographic locations, and which computing systems have implemented other execution nodes in the virtual warehouse.

[0097] The execution platform 116 is also fault tolerant. For example, if a virtual warehouse fails, the virtual warehouse will be quickly replaced by a different virtual warehouse located in a different geographical location.

[0098] A particular execution platform 116 may include any number of virtual warehouses. In addition, the number of virtual warehouses in a particular execution platform is dynamic, so that new virtual warehouses are created when additional processing and / or cache resources are needed. Similarly, existing virtual warehouses may be deleted when the resources associated with the virtual warehouses are no longer needed.

[0099] In some embodiments, virtual warehouses can operate on the same data in the storage platform 210, but each virtual warehouse has its own execution node with independent processing and cache resources. This configuration allows requests on different virtual warehouses to be processed independently without interfering with each other. This independent processing capability combined with the ability to dynamically add and remove virtual warehouses supports adding new processing capabilities for new users without affecting the performance observed by existing users.

[0100] Figure 5 5 is a block diagram depicting an example operating environment 500 in which a queue 204 communicates with multiple virtual warehouses under a virtual warehouse manager 502. In environment 500, the queue 204 can access multiple database shared storage devices 506a, 506b, 506c, 506d, 506e, and 506n through multiple virtual warehouses 504a, 504b, and 504n. Figure 5 102, but the queue 204 may access the virtual warehouses 504a, 504b, and 504n through the computing service manager 102. In certain embodiments, the databases 506a-506n are contained in the storage platform 210 and may be accessed by any virtual warehouse implemented in the execution platform 116. In some embodiments, the queue 204 may access one of the virtual warehouses 504a-504n using a data communication network such as the Internet. In some implementations, a client account may specify that the queue 204 (configured to store internal jobs to be completed) should interact with a specific virtual warehouse 504a-504n at a specific time.

[0101] In an embodiment (as shown), each virtual warehouse 504a-504n can communicate with all databases 506a-506n. In some embodiments, each virtual warehouse 504a-504n is configured to communicate with a subset of all databases 506a-506n. In such an arrangement, an individual client account associated with a collection of data can send all data retrieval and data storage requests and / or send them to a certain subset of databases 506a-506n through a single virtual warehouse. In addition, in the case where a certain virtual warehouse 504a-504n is configured to communicate with a specific subset of databases 506a-506n, the configuration is dynamic. For example, a virtual warehouse 504a can be configured to communicate with a first subset of databases 506a-506n, and can be reconfigured to communicate with a second subset of databases 506a-506n later.

[0102] In an embodiment, the queue 204 sends data retrieval, data storage and data processing requests to the virtual warehouse manager 502, which routes the requests to the appropriate virtual warehouses 504a-504n. In some implementations, the virtual warehouse manager 502 provides dynamic allocation of jobs to the virtual warehouses 504a-504n.

[0103] In some embodiments, the fault-tolerant system creates a new virtual warehouse in response to a failure of a virtual warehouse. The new virtual warehouse can be in the same virtual warehouse group, or can be created in a different virtual warehouse group in a different geographical location.

[0104] The systems and methods described herein allow data to be stored and accessed as a service separate from computing (or processing) resources. Even if no computing resources have been allocated from the execution platform 116, data can be used in the virtual warehouse without reloading the data from the remote data source. Therefore, the data is available independently of the allocation of computing resources associated with the data. The described system and method are useful for any type of data. In a specific embodiment, the data is stored in a structured optimized format. The separation of data storage / access services from computing services also simplifies data sharing between different users and groups. As described herein, each virtual warehouse can access any data with access permissions, even if other virtual warehouses are accessing the same data at the same time. The architecture supports running queries without storing any actual data in the local cache. The systems and methods described herein enable transparent dynamic data movement, which moves data from remote storage devices to local caches as needed in a transparent manner to system users. In addition, since any virtual warehouse can access any data due to the separation of data storage services from computing services, the architecture supports data sharing without previous data movement.

[0105] Figure 6 6 is a schematic diagram of a process flow 600 for retrying a failed query 104. The process flow 600 begins with an indication of a failed query 104. The indication of a failed query 104 may be a positive / negative message that only indicates that an attempt to execute the query failed and does not provide any indication of how or when the execution of the query failed. In response to the indication of the failed query 104, at 602, the computing service manager 102 or other computing resource may schedule the query to be retried on the same version of the database platform used for the original failed execution of the query. The version of the database platform may be a set of software or firmware codes that indicate how the database platform should run. If the retry of the query at 604 is successful, the result of the query is returned to the client at 610. If the retry of the query at 604 is successful, it can be inferred that the original failed execution of the query was caused by an intermittent failure. If the retry of the query at 604 is unsuccessful, the computing service manager 102 or other computing resource may schedule the query at 606 to be retried on some other version of the database platform that was not used for the original failed execution of the query. If the retry of the query at 608 is successful, the query results may be returned to the client at 610. In an embodiment, after one or more unsuccessful attempts at the query, an indication of an internal failure is sent to the client account. If the retry of the query at 608 is unsuccessful, the query may be retried again on some other version of the database platform or on the same version of the database platform. The query may be retried repeatedly until execution of the query is successful. The query may be run on any number of versions of the database platform.

[0106] If execution of the query at 604 is unsuccessful after retrying on the same version of the database platform at 602, and if execution of the query at 608 is successful after retrying on some other version of the database platform at 606, the original failed execution of the query may have failed due to a system error rather than an intermittent failure. The query may be retried multiple times until a determination can be made that the query failed due to an intermittent failure or due to a system error. System errors may include problems or program errors in the software or firmware supporting the database platform. Multiple query retry attempts may be utilized to identify program errors or bugs in the software for the database platform.

[0107] Figure 7700 is a process flow for query retry runs. In an embodiment, the default mode for the query retry system is batch-oriented, in which failed queries 104 are pre-selected and then run under different settings for comparison. This batch-oriented mode can be suitable for small and medium-sized queries, but not for larger queries. Larger queries bring several problems. One problem with larger queries is that they take longer to run, and clients continue to ingest new data into the database even if there are no schema changes. In order to compare results, the query retry system can use a fixed time travel version for each query retry, which is usually set at the beginning of the run. When running queries in real time on behalf of client accounts, it is acceptable for the query to appear to be running at any single arbitrary point after the client account first submits the query request and before the client account receives the final response. This ensures that the query execution is linearized. That is, when retrying a query, it may appear that the database is idle for a long time before starting to execute the query (in the meantime, other processes or client accounts may ingest additional data), but this is still a correct execution.

[0108] The processing flow 700 for streaming mode solves the above problems with a batch-oriented processing flow. In the streaming mode processing flow 700, the query retry module 114 determines the query configuration and run settings. In an embodiment, the failed query 104 to be rerun is incrementally selected by the workload selector 702 and added to the query queue 704, which then submits the query to the query retry runner 706. The query retry runner 706 accepts each query and multiplexes it to run with different settings before performing verification and comparison to generate a report 714. The query retry runner 706 will run a baseline run 708 and a target run 710 according to different parameters that can be determined by the query retry runner 706 or input by the query retry module 114. The results of the streaming run can be periodically flushed to a shared storage device in the database system so that a user can poll the latest results of the ongoing streaming run.

[0109] The baseline run 708 may have the same settings as the original failed execution of the query. For example, the baseline run 708 may be managed by the same compute service instance, may be executed on the same version of the database platform, and may be executed by the same execution node as the original failed execution of the query. The target run 710 may make one or more adjustments relative to the original failed execution of the query. For example, the target run 710 may be managed by a different compute service instance than the original failed execution of the query. The target run 710 may be executed on a different version of the database platform than the original failed execution of the query. The target run 710 may be executed by a different execution node than the original failed execution of the query.

[0110] Reference now Figure 8 , which shows a computer system 800 for running some of the methods disclosed herein. The computer system 800 can work with the data processing platform 200 to schedule, manage and execute all tasks of the database platform. In an embodiment, Figure 2 The illustrated computing service manager 102 is configured to manage "internal" database tasks stored in a queue 204. Such tasks are not received from client accounts, but are performed for the purpose of improving database operations. Figure 8 The resource manager 802 shown is configured to manage "external" database tasks such as query requests received from client accounts. Each of the computing service manager 102 and the resource manager 802 can be connected to the same storage platform 210, execution platform 116, and metadata 206 storage. The resource manager 802 can be configured to receive a query request from a client account and manage the original execution of the query. If the original execution of the query fails, the resource manager 802 can enter a retry request for the query in the queue 204 to be managed by the computing service manager 102. In an embodiment, the resource manager 802 includes Figure 3 All components and modules are identical to the computing service manager 102 shown.

[0111] like Figure 8 As shown, resource manager 802 can be coupled to multiple users 804, 806, 808. In a specific embodiment, resource manager 802 can support any number of users who wish to access data processing platform 300. Users 804, 806, 808 may include, for example, end users who provide data storage and retrieval requests, system administrators who manage the systems and methods described herein, and other components / devices that interact with resource manager 802. Users 804, 806, 808 may be referred to as "clients" in this article and may have direct connections to one or more deployments disclosed herein. Each of users 804, 806, 808 may be connected to a primary deployment and have the ability to transition a connection from a primary deployment to a secondary deployment.

[0112] Resource manager 802 may be coupled to metadata 206 storage associated with all data stored throughout data processing platform 300. In some embodiments, metadata 206 may include summaries of data stored in remote data storage systems and data available from local caches. Additionally, metadata 206 may include information about how data is organized in remote data storage systems and local caches. Metadata 206 may allow systems and services to determine whether a data segment needs to be processed without having to load or access the actual data from a storage device.

[0113] The resource manager 802 may be further coupled to an execution platform 116 that provides multiple computing resources for performing various data storage and data retrieval tasks, as discussed in more detail below. In an embodiment, there are one or more execution platforms 116 that are used to execute client tasks (such as database queries) and / or "internal" database tasks (such as updating metadata, clustering tables, generating materialized views, and the like). In such an embodiment, there may also be one or more execution platforms 116 for incremental feature development and / or testing, and those execution platforms 116 are separate from the client execution platforms 116 so that client processing is not affected by feature development tasks. The execution platform 116 may be coupled to multiple data storage devices 212a, 212b, 212n that are part of the storage platform 210. Although in Figure 8 1 , three data storage devices 212a, 212b, 212n are shown, but the execution platform 116 is capable of communicating with any number of data storage devices. In some embodiments, the data storage devices 212a, 212b, 212n are cloud-based storage devices located in one or more geographic locations. For example, the data storage devices 212a, 212b, 212n can be part of a public cloud infrastructure or a private cloud infrastructure. The data storage devices 212a, 212b, 212n can be hard disk drives (HDDs), solid-state drives (SSDs), storage clusters, or any other data storage technology. In addition, the storage platform 210 can include a distributed file system (such as a Hadoop distributed file system (HDFS)), an object storage system, and the like.

[0114] In a particular embodiment, the communication links between the resource manager 802 and the users 804, 806, 808, the metadata 206, and the execution platform 116 are implemented via one or more data communication networks. Similarly, the communication links between the execution platform 116 and the data storage devices 212a, 212b, 212n in the storage platform 210 are implemented via one or more data communication networks. These data communication networks can utilize any communication protocol and any type of communication medium. In some embodiments, the data communication network is a combination of two or more data communication networks (or subnetworks) coupled to each other. In an alternative embodiment, these communication links are implemented using any type of communication medium and any communication protocol.

[0115] like Figure 8 As shown, data storage devices 212a, 212b, and 212n are separated from the computing resources associated with the execution platform 116. In an embodiment, each of the multiple database deployments may include a storage platform 210 having multiple data storage devices 212a, 212b, and 212n. Each storage platform 314 across multiple deployments can store a copy of the database data, so that each of the multiple deployments can be used as a primary deployment for performing updates and queries on the database data. The architecture supports dynamic changes to the data processing platform 800 based on changing data storage / retrieval requirements and changing requirements of users and systems accessing the data processing platform 800. Support for dynamic changes allows the data processing platform 800 to scale rapidly in response to changing requirements for systems and components within the data processing platform 800. The separation of computing resources from data storage devices supports the storage of large amounts of data without the need for a corresponding large amount of computing resources. Similarly, this separation of resources supports a significant increase in computing resources used at a particular time without a corresponding increase in available data storage resources.

[0116] The resource manager 802, metadata 206, execution platform 116 and storage platform 210 are Figure 8 800. However, each of the resource manager 802, metadata 206, execution platform 116, and storage platform 210 can be implemented as a distributed system (e.g., multiple systems / platforms distributed at multiple geographical locations). In addition, each of the resource manager 802, metadata 206, execution platform 116, and storage platform 210 can be expanded or reduced (independently of each other) based on changes to requests received from users 804, 806, 808 and changes in the data processing platform 800. Therefore, the data processing platform 800 is dynamic and supports regular changes to meet current data processing needs.

[0117] In various embodiments of the present disclosure, attempts to retry queries may be managed by the resource manager 802 and / or the computing service manager 102. In an embodiment, the resource manager 802 receives the original query request from the client account, and the resource manager 802 manages the original attempt to execute the query. The resource manager 802 may pass the query to the computing service manager 102 to manage one or more attempts to retry the query. Alternatively, the same resource manager 802 that manages the original failed execution of the query may also manage one or more attempts to retry the query.

[0118] In an embodiment, the resource manager 802 is configured to assign a unique identification number to each query received from the users 804, 806, 808. The unique identification number enables the requesting user and / or client account to access and read the query and the query results. In an embodiment, when the original execution of the query fails and the retry execution of the query succeeds, the unique identification can be changed to point to the retry execution of the query instead of the original execution of the query. In an embodiment, the unique identification number is used to determine the uniform resource locator (URL) address at which the client account can access the query and / or the query results.

[0119] Fig. 9 is a schematic flow chart of a method 900 for retrying a query. The method 900 may be performed by any suitable computing resource, such as the computing service manager 102, the query retry module 114, and / or the resource manager 802. The method 900 may be performed by one or more database query managers, which may generally refer to any one of the computing service manager 102 and / or the resource manager 802.

[0120] Method 900 begins, and at 902, a computing resource receives a query for database data. At 904, the computing resource assigns execution of the query to one or more execution nodes of an execution platform, wherein the one or more execution nodes are configured to execute the query on a first version of a database platform. Method 900 continues, and at 906, the computing resource determines that execution of the query is unsuccessful. At 908, the computing resource assigns retries of the query on the first version of the database platform. At 910, the computing resource assigns retries of the query on the second version of the database platform. The computing resource may assign retries of the query to the same one or more execution nodes of the execution platform and / or other execution nodes of other execution platforms at 908 and 910. The first and second versions of the database platform may be versions of software or firmware that controls and optimizes operations for the database platform, including operations for execution of queries.

[0121] Fig.101 is a schematic flow chart of a method 1000 for retrying a query. The method 1000 may be performed by any suitable computing resource, such as the computing service manager 102, the query retry module 114, and / or the resource manager 802. The method 1000 may be performed by one or more database query managers, which may generally refer to any one of the computing service manager 102 and / or the resource manager 802.

[0122] Method 1000 begins, and at 1002, a computing resource receives a query for database data. At 1004, the computing resource distributes execution of the query to one or more execution nodes of an execution platform, wherein the one or more execution nodes are configured to execute the query on a first version of a database platform. Method 1000 continues, and at 1006, the computing resource determines that execution of the query was unsuccessful. At 1008, the computing resource distributes a retry of query execution to one or more execution nodes of the execution platform. Method 1000 continues, and at 1010, the computing resource determines whether a regression or an intermittent failure caused the query execution to be unsuccessful based on whether the retry of query execution was successful or unsuccessful.

[0123] Fig.11 1 is a schematic flow chart of a method 1100 for retrying a query. The method 1100 may be performed by any suitable computing resource, such as the computing service manager 102, the query retry module 114, and / or the resource manager 802. The method 1100 may be performed by one or more database query managers, which may generally refer to any one of the computing service manager 102 and / or the resource manager 802.

[0124] The method 1100 begins, and at 1102 a computing resource receives a query for database data. At 1104, a first database query manager distributes execution of the query to one or more nodes of an execution platform. The method 1100 continues, and at 1106, the computing resource determines that execution of the query was unsuccessful. At 1108, the first database query manager reassigns the query to a second database query manager. The method 1100 continues, and at 1110, the second database query manager distributes retries of query execution to one or more execution nodes of the execution platform.

[0125] Fig.12 1 is a schematic flow chart of a method 1200 for retrying a query. The method 1200 may be performed by any suitable computing resource, such as the computing service manager 102, the query retry module 114, and / or the resource manager 802. The method 1200 may be performed by one or more database query managers, which may generally refer to any one of the computing service manager 102 and / or the resource manager 802.

[0126] Method 1200 begins, and at 1202, a computing resource receives a query for database data, wherein the query is received from a client account. Method 1200 continues, and at 1204, the computing resource receives an indication that execution of the query was unsuccessful. At 1206, the computing resource automatically allocates one or more retries to execute the query until execution of the query is successful. Method 1200 continues, and at 1208, the computing resource records an indication of each attempt to execute the query in a transaction log associated with the client account. At 1210, the computing resource receives a request for the transaction log from the client account. At 1212, the computing resource generates a filtered transaction log by filtering out each unsuccessful attempt to execute the query. At 1214, the computing resource provides the filtered transaction log to the client account.

[0127] Fig.13 13 is a schematic flow chart of a method 1300 for retrying a query. The method 1300 may be performed by any suitable computing resource, such as the computing service manager 102, the query retry module 114, and / or the resource manager 802. The method 1300 may be performed by one or more database query managers, which may generally refer to any one of the computing service manager 102 and / or the resource manager 802.

[0128] Method 1300 begins, and at 1302, resource manager 802 receives a query for database data from a client account. At 1304, resource manager 802 distributes the original execution of the query to one or more execution nodes of the execution platform. At 1306, resource manager 802 determines that the original execution of the query was unsuccessful. At 1308, resource manager 802 transfers the query to computing service manager 102, which is configured to manage internal tasks that are not received from the client account for improving the operation of the database platform. At 1310, computing service manager 102 distributes the retry execution of the query to one or more execution nodes of the execution platform.

[0129] Fig.14 14 is a schematic flow chart of a method 1400 for retrying a query. The method 1400 may be performed by any suitable computing resource, such as the computing service manager 102, the query retry module 114, and / or the resource manager 802. The method 1400 may be performed by one or more database query managers, which may generally refer to any one of the computing service manager 102 and / or the resource manager 802.

[0130] Method 1400 begins, and at 1402 a computing resource receives a query for database data, wherein the query is received from a client account. Method 1400 continues, and at 1404 the computing resource receives an indication that execution of the query was unsuccessful, wherein execution of the query was attempted on a first version of a database platform. At 1406, the computing resource determines whether the first version of the database platform is a latest version of the database platform. At 1408, in response to determining that the first version is the latest version, the computing resource assigns a first retry execution of the query on the first version of the database platform. At 1510, the computing resource evaluates a result of at least the first retry execution to determine whether a regression may exist in the first version of the database platform.

[0131] Fig.15 1 is a block diagram depicting an example computing device 1500. In some embodiments, computing device 1500 is used to implement one or more systems and components discussed herein. For example, computing device 1500 may allow a user or administrator to access computing service manager 102 and / or resource manager 802. In addition, computing device 1500 may interact with any system and component described herein. Therefore, computing device 1500 may be used to perform various processes and tasks, such as those discussed herein. Computing device 1500 may be used as a server, client, or any other computing entity. Computing device 1500 may be any of a variety of computing devices, such as a desktop computer, a notebook computer, a server computer, a handheld computer, a tablet computer, etc.

[0132] The computing device 1500 includes one or more processors 1502, one or more memory devices 1504, one or more interfaces 1506, one or more mass storage devices 1508, and one or more input / output (I / O) devices 1510, all coupled to a bus 1512. The one or more processors 1502 include one or more processors or controllers that execute instructions stored in the one or more memory devices 1504 and / or the one or more mass storage devices 1508. The one or more processors 1502 may also include various types of computer-readable media, such as cache memory.

[0133] One or more memory devices 1504 include various computer-readable media, such as volatile memory (e.g., random access memory (RAM)) and / or nonvolatile memory (e.g., read-only memory (ROM)). One or more memory devices 1504 may also include a rewritable ROM, such as a flash memory.

[0134] One or more mass storage devices 1508 include various computer-readable media, such as magnetic tapes, disks, optical disks, solid-state memory (e.g., flash memory), etc. Various drives may also be included in one or more mass storage devices 1508 to enable reading and / or writing of various computer-readable media from various computer-readable media. One or more mass storage devices 1508 include removable media and / or non-removable media.

[0135] The one or more I / O devices 1510 include various devices that allow data and / or other information to be input to or retrieved from the computing device 1500. Example I / O devices 1510 include a cursor control device, a keyboard, a keypad, a microphone, a monitor or other display device, a speaker, a printer, a network interface card, a modem, a lens, a CCD or other image capture device, and the like.

[0136] The one or more interfaces 1506 include various interfaces that allow the computing device 1500 to interact with other systems, devices, or computing environments. The one or more example interfaces 1506 include any number of different network interfaces, such as interfaces to a local area network (LAN), a wide area network (WAN), a wireless network, and the Internet.

[0137] The bus 1512 allows the one or more processors 1502, the one or more memory devices 1504, the one or more interfaces 1506, the one or more mass storage devices 1508, and the one or more I / O devices 1510 to communicate with each other and with other devices or components coupled to the bus 1512. The bus 1512 represents one or more of several types of bus structures, such as a system bus, a PCI bus, an IEEE 1394 bus, a USB bus, and the like.

[0138] For purposes of illustration, programs and other executable program components are shown herein as discrete blocks, although it should be understood that such programs and components may reside in different storage components of the computing device 1500 at different times and be executed by one or more processors 1502. Alternatively, the systems and processes described herein may be implemented in hardware or a combination of hardware, software, and / or firmware. For example, one or more application specific integrated circuits (ASICs) may be programmed to perform one or more of the systems or processes described herein.

[0139] Example

[0140] The following examples relate to other embodiments.

[0141] Example 1 is a method. The method includes receiving a query for database data and assigning execution of the query to one or more execution nodes of a database platform, wherein the one or more execution nodes are configured to execute the query on a first version of a database platform. The method includes determining that execution of the query is unsuccessful. The method includes assigning a first retry execution of the query on the first version of the database platform. The method includes assigning a second retry execution of the query on a second version of the database platform.

[0142] Example 2 is a method according to Example 1, further comprising: determining whether a first retry execution on a database platform of a first version is successful; and determining whether a second retry execution on a database platform of a second version is successful.

[0143] Example 3 is a method according to any one of Examples 1-2, further comprising: in response to determining that the first retry execution was unsuccessful and the second retry execution was successful, generating a report indicating that a regression may exist in the first version of the database platform.

[0144] Example 4 is a method according to any one of Examples 1-3, further comprising: in response to determining that the first retry execution was successful and the second retry execution was successful, generating a report indicating that the original unsuccessful execution of the query may have failed due to an intermittent failure.

[0145] Example 5 is a method according to any one of Examples 1-4, further comprising: in response to determining that the first retry execution was unsuccessful and the second retry execution was unsuccessful, generating a report indicating one or more of the following items: a regression may exist in the first version of the database platform; a regression may exist in the second version of the database platform; or an error may exist in at least one of the one or more execution nodes of the original unsuccessful execution of the attempted query of the database platform.

[0146] Example 6 is a method according to any one of Examples 1-5, wherein: assigning execution of the query to one or more execution nodes is performed by a resource manager that receives the query for database data; a first retry execution of the assigned query is performed by a computing service manager, which is configured to manage internal database tasks that are not received from a client account; and a second retry execution of the assigned query is performed by a computing service manager, which is configured to manage internal database tasks that are not received from a client account.

[0147] Example 7 is a method according to any one of Examples 1-6, wherein allocating a first retry execution of a query on a first version of the database platform further comprises one or more of the following items: allocating a computing service manager to manage operations of the first retry execution of the query; or identifying one or more execution nodes to perform the first retry execution of the query.

[0148] Example 8 is a method according to any one of Examples 1-7, further comprising: in response to at least one of the first retry execution or the second retry execution being successful, storing a response to the query so that the client account requesting the query can access the response.

[0149] Example 9 is a method according to any of Examples 1-8, further comprising determining whether the query can be retried based on whether a structured query language (SQL) text for the query has been truncated.

[0150] Example 10 is a method according to any one of Examples 1-9, further comprising determining whether execution of the query was unsuccessful due to an internal error or a user error, wherein the internal error is an error associated with the database platform and the user error is an error associated with the text of the query, and wherein the first retry execution and the second retry execution are allocated only when the original unsuccessful execution of the query occurs due to the internal error.

[0151] Example 11 is a system. The system includes a multi-tenant cloud-based database platform, which includes multiple shared storage devices that jointly store database data and an execution platform independent of the multiple shared storage devices. The system includes one or more processors for managing database tasks. One or more processors are configured to receive queries for database data. One or more processors are configured to assign the execution of the query to one or more execution nodes of the database platform, and the one or more execution nodes are configured to execute the query on a first version of the database platform. One or more processors are configured to determine that the execution of the query is unsuccessful. One or more processors are configured to assign a first retry execution of the query on the first version of the database platform. One or more processors are configured to assign a second retry execution of the query on a second version of the database platform.

[0152] Example 12 is a system according to Example 11, wherein the one or more processors are further configured to: determine whether a first retry execution on the first version of the database platform is successful; and determine whether a second retry execution on the second version of the database platform is successful.

[0153] Example 13 is a system according to any of Examples 11-12, wherein the one or more processors are further configured to: in response to determining that the first retry execution was unsuccessful and the second retry execution was successful, generate a report indicating that a regression may exist in the first version of the database platform.

[0154] Example 14 is a system according to any one of Examples 11-13, wherein the one or more processors are further configured to: in response to determining that the first retry execution was successful and the second retry execution was successful, generate a report indicating that the original unsuccessful execution of the query may have failed due to an intermittent failure.

[0155] Example 15 is a system according to any one of Examples 11-14, wherein the one or more processors are further configured to: in response to determining that the first retry execution was unsuccessful and the second retry execution was unsuccessful, generate a report indicating one or more of the following items: there may be a regression in the first version of the database platform; there may be a regression in the second version of the database platform; or there may be an error in at least one of the one or more execution nodes of the database platform that attempted the original unsuccessful execution of the query.

[0156] Example 16 is a system according to any one of Examples 11-15, wherein: the one or more processors that assign execution of a query to one or more execution nodes are part of a resource manager that receives queries for database data; the one or more processors that assign a first retry execution of the query are part of a computing service manager that is configured to manage internal database tasks that are not received from a client account; and the one or more processors that assign a second retry execution of the query are part of a computing service manager that is configured to manage internal database tasks that are not received from a client account.

[0157] Example 17 is a system according to any one of Examples 11-16, wherein one or more processors are configured to distribute the first retry execution of the query on the first version of the database platform by one or more of the following: allocating a computing service manager to manage the operation of the first retry execution of the query; or identifying one or more execution nodes to perform the first retry execution of the query.

[0158] Example 18 is a system according to any one of Examples 11-17, wherein the one or more processors are further configured to: in response to at least one of the first retry execution or the second retry execution being successful, store a response to the query so that the client account requesting the query can access the response.

[0159] Example 19 is a system according to any of Examples 11-18, wherein the one or more processors are further configured to determine whether the query can be retried based on whether a structured query language (SQL) text for the query has been truncated.

[0160] Example 20 is a system according to any one of Examples 11-19, wherein the one or more processors are further configured to determine whether execution of the query is unsuccessful due to an internal error or a user error, wherein the internal error is an error associated with the database platform and the user error is an error associated with the text of the query, and wherein the one or more processors are configured to allocate a first retry execution and allocate a second retry execution only when the original unsuccessful execution of the query occurs due to an internal error.

[0161] Example 21 is one or more processors that can be configured to execute instructions stored in a non-transitory computer-readable storage medium. The instructions include receiving a query for database data. The instructions include allocating execution of the query to one or more execution nodes of a database platform, the one or more execution nodes being configured to execute the query on a first version of the database platform. The instructions include determining that execution of the query is unsuccessful. The instructions include allocating a first retry execution of the query on the first version of the database platform. The instructions include allocating a second retry execution of the query on the second version of the database platform.

[0162] Example 22 is one or more processors according to Example 21, wherein the instructions further include: determining whether a first retry execution on a first version of the database platform is successful; and determining whether a second retry execution on a second version of the database platform is successful.

[0163] Example 23 is one or more processors of any of Examples 21-22, wherein the instructions further comprise: in response to determining that the first retry was unsuccessful and the second retry was successful, generating a report indicating that a regression may exist in the first version of the database platform.

[0164] Example 24 is one or more processors according to any of Examples 21-23, wherein the instructions further include: in response to determining that the first retry execution was successful and the second retry execution was successful, generating a report indicating that the original unsuccessful execution of the query may have failed due to an intermittent failure.

[0165] Example 25 is one or more processors according to any one of Examples 21-24, wherein the instructions further include: in response to determining that the first retry execution was unsuccessful and the second retry execution was unsuccessful, generating a report indicating one or more of the following items: a regression may exist in the first version of the database platform; a regression may exist in the second version of the database platform; or an error may exist in at least one of the one or more execution nodes of the original unsuccessful execution of the attempted query of the database platform.

[0166] Example 26 is one or more processors according to any one of Examples 21-25, wherein the instruction causes: assigning execution of the query to one or more execution nodes to be performed by a resource manager that receives the query for database data; assigning a first retry execution of the query to be performed by a computing service manager that is configured to manage internal database tasks that are not received from a client account; and assigning a second retry execution of the query to be performed by a computing service manager that is configured to manage internal database tasks that are not received from a client account.

[0167] Example 27 is one or more processors according to any one of Examples 21-26, wherein the instruction causes allocating a first retry execution of a query on the first version of the database platform to further include one or more of the following: allocating a computing service manager to manage operations of the first retry execution of the query; or identifying one or more execution nodes to perform the first retry execution of the query.

[0168] Example 28 is one or more processors according to any of Examples 21-27, wherein the instruction further comprises: in response to at least one of the first retry execution or the second retry execution being successful, storing a response to the query so that the response is accessible to the client account requesting the query.

[0169] Example 29 is one or more processors of any of Examples 21-28, wherein the instructions further comprise determining whether the query can be retried based on whether a structured query language (SQL) text for the query has been truncated.

[0170] Example 30 is one or more processors according to any one of Examples 21-29, wherein the instructions also include determining whether execution of the query was unsuccessful due to an internal error or a user error, wherein the internal error is an error associated with the database platform and the user error is an error associated with the text of the query, and wherein the first retry execution and the second retry execution are allocated only when the unsuccessful execution of the query occurs due to the internal error.

[0171] Example 31 is a method. The method includes receiving a query for database data and assigning execution of the query to one or more execution nodes of an execution platform, the one or more execution nodes being configured to execute the query on a first version of a database platform. The method includes determining that execution of the query was unsuccessful. The method includes assigning a first retry execution of the query to one or more execution nodes of the execution platform. The method includes determining whether execution of the query was unsuccessful due to regression or intermittent failure based at least in part on whether the first retry execution of the query was successful or unsuccessful.

[0172] Example 32 is a method according to Example 31, further comprising assigning a second retried execution of the query to one or more other execution nodes that did not attempt to execute the original unsuccessful execution of the query.

[0173] Example 33 is a method according to any one of Examples 31-32, further comprising allocating a third retry execution of the query to be executed on the second version of the database platform.

[0174] Example 34 is a method according to any one of Examples 31-33, wherein determining whether regression or intermittent failure causes unsuccessful execution of the query includes determining based on results of a first retry execution, a second retry execution, and a third retry execution of the query.

[0175] Example 35 is a method according to any one of Examples 31-34, further comprising: in response to determining that the first retry execution was unsuccessful and the second retry execution was successful, generating a report indicating that the original unsuccessful execution of the query may have failed due to a problem within at least one of the one or more execution nodes.

[0176] Example 36 is a method according to any one of Examples 31-35, further comprising: in response to determining that the first retry execution was unsuccessful and the third retry execution was successful, generating a report indicating that a regression may exist in the first version of the database platform.

[0177] Example 37 is a method according to any one of Examples 31-36, further comprising: in response to determining that the first retry execution was unsuccessful, the second retry execution was unsuccessful, and the third retry execution was unsuccessful, generating a report indicating one or more of the following items: there may be a regression in the first version of the database platform; there may be a regression in the second version of the database platform; there may be a problem with at least one of the one or more execution nodes of the database platform; there may be a problem with at least one of the one or more other execution nodes associated with the second retry execution; or an intermittent failure may occur.

[0178] Example 38 is a method according to any of Examples 31-37, further comprising determining whether the query can be retried based on whether a structured query language (SQL) text for the query has been truncated.

[0179] Example 39 is a method according to any one of Examples 31-38, further comprising determining whether execution of the query was unsuccessful due to an internal error or a user error, wherein the internal error is an error associated with the database platform and the user error is an error associated with the text of the query, and wherein the first retry execution and the second retry execution are allocated only when the original unsuccessful execution of the query occurs due to the internal error.

[0180] Example 40 is a method according to any of Examples 31-39, further comprising generating a transaction log including an entry for each attempt to execute the query.

[0181] Example 41 is a method. The method includes receiving a query for database data and assigning, by a first database query manager, execution of the query to one or more execution nodes of an execution platform. The method includes determining that execution of the query was unsuccessful. The method includes reassigning, by the first database query manager, the query to a second database query manager for retrying. The method includes assigning, by the second database query manager, a retry of execution of the query to one or more execution nodes of the execution platform.

[0182] Example 42 is a method according to example 41, further comprising determining whether the query was originally executed on the new version of the database platform, and wherein the query is reassigned to the second database query manager in response to determining that the query was originally executed on the new version of the database platform.

[0183] Example 43 is a method according to any of Examples 41-42, further comprising determining whether a regression is likely to exist in the new version of the database platform based at least in part on a result of a retry of the execution of the query.

[0184] Example 44 is a method according to any of Examples 41-43, wherein in response to determining that execution of the query was unsuccessful due to an internal error, reassigning the query to a second database query manager is performed.

[0185] Example 45 is a method according to any one of Examples 41-44, further including: determining whether the execution of the query is unsuccessful due to an internal error; and in response to determining that the execution of the query is unsuccessful due to an internal error, generating an error message for the account requesting the query indicating that the query failed due to an internal error; and recording a service event indicating that the query failed due to an internal error.

[0186] Example 46 is a method according to any of Examples 41-45, wherein reassigning the query to the second database query manager is performed in response to logging a service event indicating that the query failed due to an internal error.

[0187] Example 47 is a method according to any one of Examples 41-46, wherein the first database query manager runs a first version of a database platform and the second database query manager runs a second version of a database platform, wherein the first version and the second version of the database platform are released at different times and include different software.

[0188] Example 48 is a method according to any of Examples 41-47, wherein the database platform includes a plurality of database query managers that collectively run two or more versions of the database platform at a time.

[0189] Example 49 is a method according to any one of Examples 41-48, further comprising analyzing results of retries of execution of the query to determine that execution of the query may have been unsuccessful due to an intermittent failure or regression in the first version of the database platform.

[0190] Example 50 is a method according to any of Examples 41-49, wherein assigning the retry of execution of the query comprises assigning the execution of the query to a different execution node that did not attempt execution of the query.

[0191] Example 51 is a method. The method includes receiving a query for database data from a client account and receiving an indication that an original execution of the query was unsuccessful. The method includes automatically allocating retry executions of the query until the execution of the query is successful. The method includes recording an indication of each attempt to execute the query in a transaction log associated with the client account. The method includes receiving a request for the transaction log from the client account and generating a filtered transaction log by filtering out each unsuccessful attempt to execute the query. The method includes providing the filtered transaction log to the client account.

[0192] Example 52 is a method according to Example 51, wherein automatically allocating retry executions of queries includes: allocating query retries to be managed by a first database query manager that manages the original execution of the query; and allocating query retries to be managed by a second database query manager that does not manage the original execution of the query.

[0193] Example 53 is a method according to any of Examples 51-52, further comprising analyzing all query retry attempts to determine whether the original execution of the query was unsuccessful due to an intermittent failure or due to a regression in software executed by the first database query manager.

[0194] Example 54 is a method according to any one of Examples 51-53, wherein automatically allocating query retries to be executed includes: allocating query retries to be executed by a first group of execution nodes that attempted the original execution of the query; and allocating query retries to be executed by a second group of execution nodes that did not attempt the original execution of the query.

[0195] Example 55 is a method according to any one of Examples 51-54, further comprising analyzing all query retry attempts to determine whether the original execution of the query was unsuccessful due to an intermittent failure or due to a hardware problem on at least one execution node of the first set of execution nodes.

[0196] Example 56 is a method according to any one of Examples 51-55, wherein automatically allocating retry executions of queries includes: allocating the query retries to be executed on a first version of the database platform that was used to attempt the original execution of the query; and allocating the query retries to be executed on a second version of the database platform that was not used to attempt the original execution of the query.

[0197] Example 57 is a method according to any of Examples 51-56, further comprising analyzing all query retry attempts to determine whether the original execution of the query was unsuccessful due to an intermittent failure or due to a regression in the first version of the database platform.

[0198] Example 58 is a method according to any one of Examples 51-57, wherein automatically assigning execution of retried queries includes: assigning each query retry attempt to a single instance of the database query manager so that the query retry attempt is not managed by more than one instance of the database query manager.

[0199] Example 59 is a method according to any one of Examples 51-58, wherein recording an indication of each attempt to execute a query includes recording one or more of the following: an indication of which instance of a database query manager manages each attempt; an indication of which version of the database platform is running to execute each attempt; an indication of which execution node is used to execute each attempt; an indication of when the attempt was started; or an indication of when each attempt was completed.

[0200] Example 60 is a method according to any one of Examples 51-59, further comprising: in response to receiving an indication that the original execution of the query was unsuccessful, providing a notification to the client account indicating that the original execution of the query was unsuccessful; in response to receiving an indication that at least one retry attempt was successful, providing a notification to the client account indicating that the query was successfully executed.

[0201] Example 61 is a method. The method includes receiving a query for database data from a client account. The method includes receiving an indication that an original execution of the query was unsuccessful, wherein the original execution of the query was attempted on a first version of a database platform. The method includes determining whether the first version of the database platform is a latest version of the database platform. The method includes allocating a first retry execution of the query on the first version of the database platform in response to determining that the first version is the latest version. The method includes evaluating a result of at least the first retry execution to determine whether a regression may exist in the first version of the database platform.

[0202] Example 62 is a method according to Example 61, further comprising allocating a second retry execution of the query on a second version of the database platform, wherein the second version of the database platform is not the latest version of the database platform.

[0203] Example 63 is a method according to any one of Examples 61-62, further comprising evaluating results of the first retry execution and the second retry execution to determine whether a regression may exist in the first version of the database platform.

[0204] Example 64 is a method according to any of Examples 61-63, further comprising determining whether a structured query language (SQL) text for the query has been truncated, and wherein a first retry execution of the query is assigned only if the SQL text for the query has not been truncated.

[0205] Example 65 is a method according to any of Examples 61-64, further comprising populating a transaction log of a client account, the transaction log comprising a list of all actions performed for the client account, wherein populating the transaction log includes an indication that the original execution of the input query was unsuccessful.

[0206] Example 66 is a method according to any one of Examples 61-65, further comprising determining whether the original execution of the query was unsuccessful due to an internal error, and wherein the first retry execution of the allocation query is performed only if the original execution of the query was unsuccessful due to an internal error.

[0207] Example 67 is a method according to any one of Examples 61-66, further comprising storing a record of the original execution of the query in a key-value store, wherein the record includes one or more of the following: a structured query language (SQL) text for the query; a start timestamp when execution of the query began; a completion timestamp when execution of the query failed; an indication of whether the query failed due to an internal error, an error in the SQL text for the query, or an intermittent failure; or a unique identifier for the query that enables a client account to access the query results.

[0208] Example 68 is a method according to any of Examples 61-67, wherein the query is associated with a unique identifier to enable a client account to access the query, and wherein the method further includes: receiving an indication that at least one retry attempt for the query was successful; and rerouting the unique identifier to point to the successful retry attempt rather than the original execution of the query.

[0209] Example 69 is a method according to any one of Examples 61-68, wherein assigning a first retry execution of a query includes: removing the query from a resource manager that is configured to manage external tasks received from a client account; and assigning the first retry execution to a computing service manager that is configured to manage internal tasks that are not received from a client account and are used to improve the operation of a database platform.

[0210] Example 70 is a method according to any of Examples 61-69, wherein assigning the first retry execution to the computing service manager includes entering one or more retry attempts in a queue of the computing service, wherein the queue of the computing service manager includes a list of all internal tasks for improving the operation of the database platform.

[0211] Example 71 is a method. The method includes receiving, by a first database query manager, a query for database data from a client account. The method includes assigning an original execution of the query to one or more execution nodes of an execution platform. The method includes determining that the original execution of the query was unsuccessful. The method includes transferring the query to a second database query manager, the second database query manager being configured to manage internal tasks that are not received from the client account and are used to improve the operation of the database platform. The method includes assigning, by the second database query manager, a retried execution of the query to one or more execution nodes of the execution platform.

[0212] Example 72 is the method of Example 71, wherein the first database query manager is configured to manage external tasks received from the client account.

[0213] Example 73 is a method according to any one of Examples 71-72, further comprising identifying the second database query manager based on one or more of the following: whether the second database query manager is implementing the same version of the database platform as the first database query manager; the workload of the second database query manager; or whether the version of the database platform implemented by the first database query manager and / or the second database query manager is the latest version of the database platform.

[0214] Example 74 is a method according to any one of Examples 71-73, further comprising: in response to determining that the first database query manager and the second database query manager are implementing the same version of the database platform, transferring the query to the second database query manager, and further assigning the query to a third database query manager, which is configured to manage internal tasks and implement different versions of the database platform.

[0215] Example 75 is a method according to any one of Examples 71-74, wherein transferring the query to the second database query manager includes: inputting the query as a job into a queue of the second database query manager, wherein the queue receives multiple jobs for improving the operation of the database platform.

[0216] Example 76 is a method according to any one of Examples 71-75, wherein one or more execution nodes that execute the original execution of the attempted query of the execution platform each run the same version of the database platform, wherein the database platform includes multiple execution nodes that collectively run multiple versions of the database platform.

[0217] Example 77 is a method according to any one of Examples 71-76, further comprising determining whether the retried execution of the query should be assigned to one or more execution nodes of the execution platform that attempted the original execution of the query based on one or more of the following: whether the one or more execution nodes are running the latest version of the database platform; whether a problem has been identified in a server of at least one of the one or more execution nodes; whether the one or more execution nodes have at least a portion of data responsive to the query stored in cache storage; storage availability of the one or more execution nodes; or processing availability of the one or more execution nodes.

[0218] Example 78 is a method according to any one of Examples 71-77, wherein the database platform includes multiple database query managers that together implement two or more versions of the database platform, and wherein a new version of the database platform is implemented on a portion of the multiple database query managers.

[0219] Example 79 is a method according to any one of Examples 71-78, wherein the client account is a tenant in a multi-tenant cloud-based database platform, and the method further includes: tracking the amount of processing resources used to perform an original execution of a query and a retried execution of the query; associating the tracked processing resources with the client account; and providing the client account with a log of all processing resources used by the client account.

[0220] Example 80 is a method according to any one of Examples 71-79, further comprising determining whether the original execution of the query failed due to an error in a structured query language (SQL) text of the query or due to an internal error, wherein the method comprises: transferring the query to a second database query manager only if the original execution of the query failed due to an internal error.

[0221] Example 81 is an apparatus for implementing any of the methods of Examples 1-80.

[0222] Example 82 is a non-transitory computer-readable storage medium storing instructions for implementing any of the methods of Examples 1-80.

[0223] Example 83 is a multi-tenant cloud-based database platform comprising a processor configurable to execute instructions stored in a non-transitory computer-readable storage medium, wherein the instructions include any of the methods described in Examples 1-80.

[0224] Example 84 is one or more processors configurable to execute instructions, wherein the instructions include any of the methods described in Examples 1-80.

[0225] Many functional units described in this specification may be implemented as one or more components, which are terms used to more specifically emphasize their implementation independence. For example, components may be implemented as hardware circuits including customized very large scale integration (VLSI) circuits or gate arrays, off-the-shelf semiconductors such as logic chips, transistors or other discrete components. Components may also be implemented in programmable hardware devices (such as field programmable gate arrays, programmable array logic, programmable logic devices, etc.).

[0226] Components may also be implemented in software so as to be executed by various types of processors. The identified components of executable code may, for example, include one or more physical or logical blocks of computer instructions, which may, for example, be organized as objects, programs, or functions. However, the executable files of the identified components need not be physically located together, but may include different instructions stored in different locations, which, when logically connected together, include the components and achieve the stated purpose of the components.

[0227] In practice, the components of executable code may be a single instruction or many instructions, and may even be distributed over several different code segments, in different programs, and on several storage devices. Similarly, operational data may be identified and described herein within the components, and may be embodied in any suitable form and organized within any suitable type of data structure. The operational data may be collected as a single data set, or may be distributed over different locations including different storage devices, and may exist at least in part only as electronic signals on a system or network. Components may be passive or active, including agents operable to perform desired functions.

[0228] References throughout this specification to "example" mean that the features, structures, or characteristics described in conjunction with the example are included in at least one embodiment of the present disclosure. Therefore, the phrase "in an example" appearing in various places throughout this specification does not necessarily refer to the same embodiment.

[0229] As used herein, for convenience, multiple items, structural elements, constituent elements, and / or materials may be presented in a common list. However, these lists should be interpreted as if each member in the list were individually identified as an independent and unique member. Therefore, based solely on its representation in a common group without an indication to the contrary, any individual member in such a list should not be interpreted as being substantially equivalent to any other member in the same list. In addition, various embodiments and examples of the present disclosure and alternatives to its various components may be referenced herein. It should be understood that these embodiments, examples, and alternatives should not be interpreted as actual equivalents of each other, but should be regarded as separate and autonomous representations of the present disclosure.

[0230] Although the foregoing has been described in detail for the sake of clarity, it will be apparent that certain changes and modifications may be made without departing from its principles. It should be noted that there are many alternative ways to implement the processes and devices described herein. Therefore, the present embodiment should be considered illustrative rather than restrictive.

[0231] Those skilled in the art will appreciate that many changes may be made to the details of the above embodiments without departing from the basic principles of the present disclosure. Therefore, the scope of the present disclosure should be determined solely by the appended claims.

[0232] Furthermore, it should be noted, and with particular reference to the appended claims, that unless otherwise specified, "a first retry attempt," "a second retry attempt," "a third retry attempt," etc. are not necessarily performed in order. The inclusion of indicators such as "first," "second," "third," etc. is merely to simplify reference and is not intended to limit the scope of the claims. The parameters of the different retry attempts may be performed in any order and are not limited by the "first," "second," and "third" indicators.

Claims

1. A method comprising: receiving, by a first database query manager of a database platform including at least one hardware processor, a query for database data stored on the database platform, the first database query manager being configured to manage external tasks of the database platform; assigning, by the first database query manager, an initial attempt to execute the query on a first version of the database platform to one or more execution nodes of the database platform; determining, by the first database query manager, that the initial attempt to execute the query was unsuccessful; as well as Based on the unsuccessful initial attempt: identifying a second database query manager for the database platform based on whether the second database query manager is implementing the same version of the database platform as the first database query manager; and The query is transferred by the first database query manager to the second database query manager, which is configured to manage internal tasks of the database platform. The transfer of the query causes the second database query manager to assign a first retry attempt to execute the query to one or more execution nodes of the database platform.

2. The method according to claim 1, further comprising: Based on the failure of the initial attempt or the first retry attempt, allocating, by the second database query manager, a second retry attempt to execute the query on the second version of the database platform to one or more execution nodes of the database platform; The first version of the database platform and the second version of the database platform execute different versions of the software of the database platform; determining whether the first retry attempt to execute the query on the first version of the database platform was successful or unsuccessful; and A determination is made as to whether the second retry attempt to execute the query on the second version of the database platform is successful or unsuccessful.

3. The method according to claim 2, further comprising: In response to determining that the first retry attempt was unsuccessful and the second retry attempt was successful, a report is generated indicating that a regression may exist in the first version of the database platform.

4. The method according to claim 2, further comprising: In response to determining that the first retry attempt was successful and the second retry attempt was successful, a report is generated indicating that the initial attempt to execute the query was unsuccessful, possibly due to an intermittent failure in the database platform.

5. The method according to claim 2, further comprising: In response to determining that the first retry attempt was unsuccessful and the second retry attempt was unsuccessful, generating a report indicating: There may be a regression in the first version of the database platform; There may be a regression in the second version of the database platform; and At least one of the one or more execution nodes of the database platform that is assigned the initial attempt to execute the query may have an error.

6. The method according to claim 2, wherein: the allocation of said initial attempt to execute said query being performed by a resource manager that received said query; The allocating of the first retry attempt to execute the query is performed by a computing service manager configured to manage internal database tasks; as well as The assignment of the second retry attempt to execute the query is performed by the computing service manager.

7. The method according to claim 1 or claim 2, wherein: The allocation of the first retry attempt to execute the query on the first version of the database platform includes one or more of the following: assigning a computing service manager to manage operations for executing the first retry attempt of the query; as well as The one or more execution nodes assigned to execute the first retry attempt of the query are identified.

8. The method according to claim 2, further comprising: Responsive to at least one of the first retry attempt and the second retry attempt being successful, storing a response to the query.

9. The method of claim 1 or claim 2, further comprising determining to retry execution of the query based on a structured query language (SQL) text for the query having not been truncated.

10. The method according to claim 2, wherein: In response to determining that the initial attempt to execute the query was unsuccessful due to an internal error associated with the database platform rather than an error associated with the text of the query, allocating the first retry attempt and allocating the second retry attempt are performed.

11. A system comprising: A database platform, the database platform comprising: a plurality of shared storage devices for jointly storing database data, an execution platform independent of the plurality of shared storage devices, a first database query manager, and a second database query manager; and One or more processors configured to execute instructions for performing operations comprising: receiving, by the first database query manager, a query for the database data, the first database query manager being configured to manage external tasks of the database platform; allocating, by the first database query manager, an initial attempt to execute the query on a first version of the database platform to one or more execution nodes of the execution platform; determining, by the first database query manager, that the initial attempt to execute the query was unsuccessful; and Based on the unsuccessful initial attempt: identifying a second database query manager for the database platform based on whether the second database query manager is implementing the same version of the database platform as the first database query manager; and The query is transferred by the first database query manager to the second database query manager, which is configured to manage internal tasks of the database platform. The transfer of the query causes the second database query manager to assign a first retry attempt to execute the query to one or more execution nodes of the execution platform.

12. The system of claim 11, the operations further comprising: Based on the failure of the initial attempt or the first retry attempt, allocating, by the second database query manager, a second retry attempt to execute the query on a second version of the database platform to one or more execution nodes of the execution platform; The first version of the database platform and the second version of the database platform execute different versions of the software of the database platform; determining whether the first retry attempt to execute the query on the first version of the database platform was successful or unsuccessful; and A determination is made as to whether the second retry attempt to execute the query on the second version of the database platform is successful or unsuccessful.

13. The system of claim 12, the operations further comprising: In response to determining that the first retry attempt was unsuccessful and the second retry attempt was successful, a report is generated indicating that a regression may exist in the first version of the database platform.

14. The system of claim 12, the operations further comprising: In response to determining that the first retry attempt was successful and the second retry attempt was successful, a report is generated indicating that the initial attempt to execute the query was unsuccessful, possibly due to an intermittent failure in the database platform.

15. The system of claim 12, the operations further comprising: In response to determining that the first retry attempt was unsuccessful and the second retry attempt was unsuccessful, generating a report indicating: There may be a regression in the first version of the database platform; There may be a regression in the second version of the database platform; and At least one of the one or more execution nodes of the execution platform to which the initial attempt to execute the query is assigned may be faulty.

16. The system of claim 12, wherein: the allocation of said initial attempt to execute said query being performed by a resource manager that received said query; The allocating of the first retry attempt to execute the query is performed by a computing service manager configured to manage internal database tasks; as well as The assignment of the second retry attempt to execute the query is performed by the computing service manager.

17. A system according to claim 11 or claim 12, wherein: The allocation of the first retry attempt to execute the query on the first version of the database platform includes one or more of the following: assigning a computing service manager to manage operations for executing the first retry attempt of the query; as well as The one or more execution nodes assigned to execute the first retry attempt of the query are identified.

18. The system of claim 12, the operations further comprising: Responsive to at least one of the first retry attempt and the second retry attempt being successful, storing a response to the query.

19. The system of claim 11 or claim 12, the operations further comprising determining to retry execution of the query based on a structured query language (SQL) text for the query having not been truncated.

20. The system of claim 12, wherein: In response to determining that the initial attempt to execute the query was unsuccessful due to an internal error associated with the database platform rather than an error associated with the text of the query, allocating the first retry attempt and allocating the second retry attempt are performed.

21. One or more computer-readable storage media storing instructions that, when executed by one or more processors, cause the one or more processors to perform operations comprising: receiving, by a first database query manager of a database platform, a query for database data stored on the database platform, the first database query manager being configured to manage external tasks of the database platform; allocating, by the first database query manager, an initial attempt to execute the query on a first version of the database platform to one or more execution nodes of the database platform; determining, by the first database query manager, that the initial attempt to execute the query was unsuccessful; as well as Based on the unsuccessful initial attempt: identifying a second database query manager for the database platform based on whether the second database query manager is implementing the same version of the database platform as the first database query manager; and The first database query manager transfers the query to the second database query manager, which is configured to manage internal tasks of the database platform. The transfer of the query causes the second database query manager to distribute a first retry attempt to execute the query to one or more execution nodes of the database platform.

22. The computer-readable storage medium of claim 21, wherein: The operations also include: Based on the failure of the initial attempt or the first retry attempt, allocating, by the second database query manager, a second retry attempt to execute the query on a second version of the database platform to one or more execution nodes of the database platform; The first version of the database platform and the second version of the database platform execute different versions of the database platform software. determining whether the first retry attempt to execute the query on the first version of the database platform was successful or unsuccessful; and A determination is made as to whether the second retry attempt to execute the query on the second version of the database platform is successful or unsuccessful.

23. The computer-readable storage medium of claim 22, wherein: The operations also include, in response to determining that the first retry attempt was unsuccessful and the second retry attempt was successful, generating a report indicating that a regression may exist in the first version of the database platform.

24. The computer-readable storage medium of claim 22, wherein: The operations further include, in response to determining that the first retry attempt was successful and the second retry attempt was successful, generating a report indicating that the initial attempt to execute the query may have been unsuccessful due to an intermittent failure in the database platform.

25. The computer-readable storage medium of claim 22, wherein: The operations also include, in response to determining that the first retry attempt was unsuccessful and the second retry attempt was unsuccessful, generating a report indicating: There may be a regression in the first version of the database platform; There may be a regression in the second version of the database platform; and At least one of the one or more execution nodes of the database platform that is assigned the initial attempt to execute the query may have an error.

26. The computer-readable storage medium of claim 22, wherein: the allocation of said initial attempt to execute said query being performed by a resource manager that received said query; The allocating of the first retry attempt to execute the query is performed by a computing service manager configured to manage internal database tasks; as well as The assignment of the second retry attempt to execute the query is performed by the computing service manager.

27. The computer-readable storage medium of claim 21 or claim 22, wherein: The allocation of the first retry attempt to execute the query on the first version of the database platform includes one or more of the following: assigning a computing service manager to manage operations for executing the first retry attempt of the query; as well as The one or more execution nodes assigned to execute the first retry attempt of the query are identified.

28. The computer-readable storage medium of claim 22, wherein: The operations also include storing a response to the query in response to at least one of the first retry attempt and the second retry attempt being successful.

29. The computer-readable storage medium of claim 21 or claim 22, wherein: The operations also include determining to retry execution of the query based on a structured query language (SQL) text for the query not being truncated.

30. The computer-readable storage medium of claim 22, wherein: In response to determining that the initial attempt to execute the query was unsuccessful due to an internal error associated with the database platform rather than an error associated with the text of the query, allocating the first retry attempt and allocating the second retry attempt are performed.

Images