AUTOMATIC DETECTION OF DATABASE CRITICALITY

In one embodiment, a database object stored in a database is identified, and a transaction history associated with the database object is accessed. A criticality level associated with the database object is determined based on the transaction history, and one or more database maintenance tasks associated with the database object are configured based on the criticality level.

BACKGROUND

This disclosure relates in general to the field of database management, and more particularly, though not exclusively, to automatic detection of database criticality.

A database administrator (DBA) is typically tasked with configuring, managing, and maintaining a database management system (DBMS) in order to facilitate efficient access to the underlying data. For example, a database administrator may regularly perform, schedule, or configure various database maintenance or “housekeeping” tasks, such as data backup and recovery, performance optimizations, and so forth. In order to perform the appropriate database maintenance tasks, however, a database administrator needs to understand which database objects are used by which applications, as well as the criticality or importance of the respective applications and their associated database objects, among other information. A database administrator typically has to derive this information manually, which can often be a tedious and error-prone task, particularly as the scale and complexity of a system increases.

BRIEF SUMMARY

According to one aspect of the present disclosure, a database object stored in a database is identified, and a transaction history associated with the database object is accessed. A criticality level associated with the database object is determined based on the transaction history, and one or more database maintenance tasks associated with the database object are configured based on the criticality level.

DETAILED DESCRIPTION OF EXAMPLE EMBODIMENTS

Example embodiments that may be used to implement the features and functionality of this disclosure will now be described with more particular reference to the attached FIGURES.

FIG. 1illustrates an example embodiment of a computing system100that provides automatic database criticality detection in accordance with certain embodiments. In the illustrated embodiment, for example, system100includes a database management system (DBMS)110that automatically detects the criticality of objects115in a database in order to facilitate database administration, as described further below.

Large enterprises typically run a variety of business applications120that are designed to provide certain services and/or interact with users, such as customers, employees, and so forth. In the illustrated embodiment, business applications120are hosted or deployed on one or more datacenter servers104and are designed to communicate and/or interact with other components of system100via network106. In some embodiments, for example, business applications120may interact with users via client devices102a-c,such as mobile devices, laptops, desktops, kiosks, ATMs, and so forth. Moreover, business applications120may rely on a database management system (DBMS)110to manage large volumes of data that are required by the applications. Examples of commercially available database management systems include IBM DB2, Oracle, MySQL, and Microsoft SQL Server, among others. In some embodiments, DBMS110may manage access to data using a query language, such as the Structured Query Language (SQL). Further, DBMS110may store and/or organize the data using various types of database objects115, such as indexes, tables, views, and so forth.

A database administrator (DBA) is typically tasked with configuring, managing, and maintaining a database management system (DBMS) in order to facilitate efficient access to the underlying data. For example, a database administrator may regularly perform, schedule, or configure various database maintenance or “housekeeping” tasks, such as data backup and recovery, performance optimizations, and so forth. Typically, a database administrator must perform manual inspections in order to determine how to best define the maintenance tasks for each database object managed by the database management system. For example, in order to perform the appropriate database maintenance tasks, a database administrator needs to understand which database objects are used by which business applications, the relationships between the respective business applications, and the criticality or importance of the respective business applications and their associated database objects. Traditionally, a database administrator would have to derive this information manually due to the lack of suitable programmatic approaches. However, techniques for automatically identifying groups of related business applications and their associated database objects have been presented in U.S. patent application Ser. Nos. 14/669,081 and 14/673,957, respectively filed on Mar. 26, 2015 and Mar. 31, 2015, entitled “Grouping of Database Objects,” the contents of which are hereby expressly incorporated by reference.

In order to properly perform the appropriate database maintenance and housekeeping tasks, however, a database administrator also needs to understand the business criticality of the various business applications and their associated database objects. Business criticality, for example, may refer to the impact on a business that results from poor performance, downtime, and/or unavailability of a particular business application and/or an associated database object. The business criticality is typically higher for applications and/or database objects that have a larger impact on the business, and lower for those that have a smaller impact on the business. A database administrator typically has to determine the business criticality of each application and/or database object manually, as there were previously no suitable programmatic approaches available for that purpose. This task might be somewhat easier if the respective lines of business (LOBs) were each able to specify the business impact of their associated business applications at a granular level, but that is often difficult, impractical, or impossible, particularly for large enterprises with many LOBs and associated business applications.

Accordingly, in the illustrated embodiment, database management system (DBMS)110automatically detects the criticality of business applications120and/or associated database objects115in computing system100in order to facilitate database administration. In some embodiments, for example, the criticality of the database objects115associated with a particular business application120may be determined by analyzing the transaction history of the respective database objects115. For example, a database management system typically maintains a transaction log that reflects past transactions associated with each database object, such as transactions performed pursuant to SQL queries, statements, or commands issued by applications, users, administrators, and so forth. The transaction log typically includes a variety of information associated with each transaction, such as the particular SQL command or transaction that was executed (e.g., SELECT, UPDATE, INSERT, CREATE, DELETE), the relevant database object(s) implicated by the command (e.g., database tables, indexes, procedures), any parameters specified by the command (e.g., data to be stored or retrieved), an identifier of the application and/or user that generated the command, a timestamp with the time and date of the command, and so forth. Moreover, various metrics associated with each database object may also be computed and/or tracked based on the past transactions, such as an SQL hit ratio, copy or backup frequency, reorganization frequency, and so forth. In this manner, the criticality of the database objects115associated with a particular business application120may be determined by analyzing the transaction history and/or metrics of the corresponding database objects115, such as the SQL hit ratio, copy frequency, and/or reorganization frequency, among other examples.

In some embodiments, for example, a business criticality index (BCI) may be computed for each business application120based on the metrics tracked for its associated database objects115, and a criticality level may then be assigned to each application120based on its computed BCI. The BCI for each business application120can be computed using any appropriate methodology or formula, such as a weighted average of the relevant metrics tracked for its associated database object(s)115(e.g., hit ratio, copy frequency, reorganization frequency), among numerous other possibilities. In some cases, for example, a BCI may be computed as a numerical value within a certain range or interval, such as a value in the range [0, 1] or [0, 100], such that the magnitude of the BCI is indicative of the level of criticality of the business application120.

A criticality level may then be assigned to each application120based on its computed BCI, such as a criticality level of LOW, MEDIUM, HIGH, or CRITICAL. In some embodiments, for example, the criticality levels could be defined statically based on predetermined BCI ranges, such as the following:

Alternatively, the criticality levels could be determined dynamically, such as based on the statistical distribution of BCIs and/or using machine learning techniques. For example, the criticality levels could be defined using varying BCI ranges derived from the statistical distribution of BCIs for all business applications120and/or database objects115(e.g., as illustrated inFIG. 6). As another example, the criticality levels could be dynamically determined using machine learning techniques. For example, the transaction metrics associated with the database objects115(and/or the BCIs or statistical distribution of BCIs computed from those metrics) could be supplied as input to a machine learning clustering algorithm, which then partitions the database objects115and/or the associated business applications120into different clusters or tiers that each correspond to a particular criticality level (e.g., as illustrated inFIG. 7).

Further, in some embodiments, the criticality levels could be determined using a combination of the approaches described above. Moreover, in varying embodiments, the criticality levels and/or BCIs may either be determined for each individual database object115, or for each business application120based on an associated group of database objects115. It should also be appreciated that the approaches described above are merely examples of how the criticality of business applications120can be derived from the transaction metrics of database objects115. Accordingly, in other embodiments, any suitable approach may be used to compute BCIs and/or determine criticality levels based on the transaction metrics of database objects115.

Once the criticality of the respective business applications120and/or database objects115has been determined, the appropriate database maintenance tasks for the database objects115can then be set up, configured, and/or scheduled. For example, when the BCI and/or criticality level of each business application120is known, the database administrator has a clear and simplified view of each database object115and can verify that the current maintenance tasks are properly configured. For example, based on the criticality level of each application120and possibly any service level agreements (SLAs) that may be in place, various database maintenance or “housekeeping” tasks may be configured and/or scheduled for each database object115, such as data backup and recovery, performance optimizations, and so forth. For example, based on the respective criticality levels, the maintenance tasks may be configured for the database objects115in a manner that satisfies any service level agreements (SLAs) that have been defined by the business.

An example database maintenance configuration is illustrated below in TABLE 1. In the illustrated example, maintenance tasks for reorganizing and copying (e.g., backing up) database objects are defined on a per-criticality level basis. For example, reorganization is defined based on a threshold level of organization that must be maintained for the database objects in each criticality level, while copying is defined based on a specified copy frequency for the database objects in each criticality level. In this manner, maintenance tasks are triggered for database objects based on the configuration parameters for their respective criticality levels. For example, based on the configuration in TABLE 1, a database object with a criticality level of “HIGH” may be reorganized whenever necessary to maintain a 95% level of organization, and may further be copied or backed up once per day.

TABLE 1Database maintenance configuration based on criticalityCOPYCRITICALITY LEVELREORG THRESHOLDFREQUENCYCRITICAL>99%HourlyHIGH>95%DailyMEDIUM>90%WeeklyLOW>80%Monthly

Further, throughout the ordinary course of business, it is common for a business to create new database objects115and/or deploy new business applications120. When a new database object115and/or business application120is initially created and/or deployed, however, the transaction metrics required to reliably determine a criticality level using the approach described above may not be immediately available, as those metrics may not exist yet or may otherwise be incomplete. Accordingly, before relying on the approach described above, it may be desirable to wait until the transaction metrics have matured, such as after the metrics have been collected for some minimum or threshold amount of time.

In some embodiments, however, machine learning may be leveraged in order to predict the criticality of a new database object115and/or business application120before its transaction metrics have matured. For example, the transaction metrics and corresponding criticality data computed for existing database objects115and/or business applications120may be used to train a machine learning model to predict the criticality of new database objects115and/or business applications120. In this manner, the criticality of a new database object115and/or business application120can initially be predicted using machine learning based on the limited transaction metrics that are immediately available, and the predicted criticality can subsequently be updated once the transaction metrics have matured such that a reliable criticality level can be determined.

Additional details and embodiments associated with automatic database criticality detection are described throughout this disclosure in connection with the remaining FIGURES.

In general, elements of computing system100, such as “systems,” “servers,” “services,” “devices,” “clients,” “networks,” “computers,” and any components thereof, may be used interchangeably herein and refer to computing devices operable to receive, transmit, process, store, or manage data and information associated with computing system100. Moreover, as used in this disclosure, the term “computer,” “processor,” “processor device,” or “processing device” is intended to encompass any suitable processing device. For example, elements shown as single devices within computing system100may be implemented using a plurality of computing devices and processors, such as server pools comprising multiple server computers. Further, any, all, or some of the computing devices may be adapted to execute any operating system, including Linux, other UNIX variants, Microsoft Windows, Windows Server, Mac OS, Apple iOS, Google Android, etc., as well as virtual machines adapted to virtualize execution of a particular operating system, including customized and/or proprietary operating systems.

Moreover, elements of computing system100(e.g., client devices102a-c,servers104, network106, database management system110, and so forth) may each include one or more processors, computer-readable memory, and one or more interfaces, among other features and hardware. Servers may include any suitable software component or module, or computing device(s) capable of hosting and/or serving software applications and services, including distributed, enterprise, or cloud-based software applications, data, and services. For instance, one or more of the described components of computing system100, may be at least partially (or wholly) cloud-implemented, “fog”-implemented, web-based, or distributed for remotely hosting, serving, or otherwise managing data, software services, and applications that interface, coordinate with, depend on, or are used by other components of computing system100. In some instances, elements of computing system100may be implemented as some combination of components hosted on a common computing system, server, server pool, or cloud computing system, and that share computing resources, including shared memory, processors, and interfaces.

Further, the network(s)106used to communicatively couple the components of computing system100may be implemented using any suitable computer communication or network technology for facilitating communication between the participating components. For example, one or a combination of local area networks, wide area networks, public networks, the Internet, cellular networks, Wi-Fi networks, short-range networks (e.g., Bluetooth or ZigBee), and/or any other wired or wireless communication medium may be utilized for communication between the participating devices, among other examples.

WhileFIG. 1is described as containing or being associated with a plurality of elements, not all elements illustrated within computing system100ofFIG. 1may be utilized in each alternative implementation of the embodiments of this disclosure. Additionally, one or more of the elements described in connection with the examples ofFIG. 1may be located external to computing system100, while in other instances, certain elements may be included within or as a portion of one or more of the other described elements, as well as other elements not described in the illustrated implementation. Further, certain elements illustrated inFIG. 1may be combined with other components, as well as used for alternative or additional purposes in addition to those purposes described herein.

Additional embodiments and functionality associated with the implementation of computing system100are described further in connection with the remaining FIGURES. Accordingly, it should be appreciated that computing system100ofFIG. 1may be implemented with any aspects or functionality of the embodiments described throughout this disclosure.

FIG. 2illustrates an example embodiment of a database criticality detection system200. In some embodiments, for example, database criticality detection system200may be used to implement the automatic database criticality detection functionality described throughout this disclosure.

In the illustrated embodiment, database criticality detection system200includes a database management system210in communication with a plurality of business applications220. Business applications220, for example, may include any type of software or computing component, such as a software application, program, microservice, microservice application, library, module, and/or any portion or component of a larger, multi-tiered software system, among other examples. Moreover, business applications220may rely on database management system (DBMS)210to manage large volumes of data that are required by the applications.

Database management system210includes a processor211, memory element212, communication interface213, data storage214, and database manager217. Processor211may be used to execute logic and/or instructions stored in memory212, such as the logic and/or instructions used to implement database manager217. Communication interface213may be used to communicate with external systems and components, such as business applications220, as well as other database management systems210in distributed embodiments. Data storage214is used to implement a database for storing large volumes of data within a variety of database objects215. Database manager217is used to manage the data stored on data storage214. For example, database manager217may organize the data into a variety of database objects215, such as indexes, tables, views, and so forth. Moreover, database manager217includes a query engine218to manage access to the data stored in the database objects215(e.g., using a query language such as SQL). Database manager217also includes an optimization engine219to optimize the performance of database management system210. In some embodiments, for example, optimization engine219may be used to implement the automatic database criticality detection functionality described throughout this disclosure.

In some implementations, the various illustrated components of database criticality detection system200, and/or any other associated components, may be combined, or even further divided and distributed among multiple different systems. For example, in some implementations, database management system210may be implemented as a single component, device, or system, or alternatively may be distributed across multiple distinct components, devices, or systems that respectively include varying combinations of its underlying components (e.g.,211-219). As another example, in various embodiments, optimization engine219may be implemented as an integrated component within database manager217or alternatively as a separate application that operates in conjunction with database manager217.

FIG. 3illustrates a process flow300for an example embodiment of automatic database criticality detection. In some embodiments, process flow300may be implemented using the components and functionality described throughout this disclosure (e.g., computing system100ofFIG. 1and/or database criticality detection system200ofFIG. 2).

The process flow begins by obtaining a list301of business application groups deployed by a particular business, along with a list302of database objects that are used by each business application group. The concept of a business application group is illustrated byFIG. 4, which depicts an example400of the hierarchical relationship between business application groups410, programs420, database objects430, and physical storage440. A business application group410, for example, may refer to one or more business applications that have a close relationship, such as a group of business applications that collectively provide a particular service or otherwise serve a similar business purpose. A business application group410is typically a subset of a larger collection of applications or programs420that are deployed by a particular business or enterprise. Moreover, some or all of those applications or programs420may depend on data that is maintained in a database using a collection of database objects430(e.g., tables, indexes), which may be physically stored on one or more physical storage devices440. In the illustrated example, the database objects430are distributed across a collection of physical storage devices440.

Turning back toFIG. 3, the list301of business application groups and the list302of corresponding database objects may either be created manually (e.g., by a database administrator) or generated automatically (e.g., using the techniques presented in U.S. patent application Ser. Nos. 14/669,081 and 14/673,957).

In order to perform the appropriate database maintenance and housekeeping tasks, however, a database administrator also needs to understand the business criticality or importance of the various business application groups and their associated database objects. An example of typical business application groups with varying levels of criticality is illustrated inFIG. 5. In the example500ofFIG. 5, business application groups510a-hare designated with criticality levels505a-d.For example, payroll510aand reporting510bare designated with a criticality level of LOW505a,enterprise resource planning (ERP)510cand human resources (HR)510dare designated with a criticality level of MEDIUM505b,supply510eand transactions510fare designated with a criticality level of HIGH505c,and orders510gand customer support510hare designated with a criticality level of CRITICAL505d.

The task of determining the criticality of each business application group for database maintenance purposes has traditionally been performed manually by a database administrator. Turning back toFIG. 3, however, that task is now performed programmatically. For example, inFIG. 3, the criticality of each business application group is determined by analyzing transaction information and/or metrics associated with the underlying database object(s), such as SQL hit ratio, copy frequency, reorganization frequency, and so forth.

Accordingly, after the lists of business application groups and associated database objects301,302have been obtained, the process flow then proceeds to blocks304-307, where various types of transaction data and/or metrics are collected from the database management system (DBMS)303for each database object of each business application group. For example, beginning with the first database object of the first business application group, the following types of transaction data may be collected: SQL hit ratio (block304), copy frequency (block305), reorganization frequency (block306), and/or any other transaction metrics or information (block307).

The SQL hit ratio, for example, may indicate a number or percentage of all queries that resulted in a hit on the particular database object (e.g., a ratio of the number of SQLs statements that hit the particular database object over the total number of SQLs statements in the DBMS workload). In this manner, based on the assumption that critical business application groups tend to be used more heavily, their underlying database objects will get hit more frequently, and thus their hit ratio will be higher.

The copy frequency may indicate the number of image copies (e.g., backups) taken of the particular database object per a certain time interval. In this manner, based on the assumption that critical business application groups likely have more stringent SLA requirements for backup and recovery, their underlying database objects are likely to be copied more frequently than others.

The reorganization frequency may indicate the number of reorganizations performed on the particular database object per a certain time interval. In this manner, based on the assumption that critical business application groups require very high performance, their underlying database objects are likely to be reorganized more frequently than others (e.g., for performance purposes).

In some cases, for example, the copy frequency and reorganization frequency may be based on a time interval of one year. If metrics for the particular database object are not available for the full time interval, however, in some cases they may extrapolated for the full time interval based on the length of history available. Moreover, in some embodiments, the transaction data may be collected from a transaction log maintained by the database management system (DBMS). For example, with respect to an IBM DB2 database management system, the copy frequency and/or reorganization frequency may be derived or extracted from data in the SYSCOPY table. Moreover, in various embodiments, other types of transaction metrics may also be used, depending on what type of data is available in the particular database management system (DBMS).

The process flow then proceeds to block308, where the transaction data collected for the particular database object is stored in a table of aggregated object metrics311.

The process flow then proceeds to block309to determine whether all database objects of the current business application group have been processed, and similarly to block310to determine whether all business application groups have been processed. In this manner, the process flow continues cycling through blocks304-308until metrics for every database object of every business application group have been collected and stored in the object metrics table311. An example of the resulting object metrics table311is illustrated inFIG. 3and is also shown below in TABLE 2.

The process flow then proceeds to block312to determine the criticality313of each business application group based on the object metrics311. In some embodiments, for example, a business criticality index (BCI) may be computed for each business application group based on the transaction metrics, and a criticality level may then be assigned to each business application group based on its computed BCI. The BCI for each business application group can be computed using any appropriate methodology or formula, such as a weighted average of the relevant metrics tracked for its associated database object(s) (e.g., hit ratio, copy frequency, reorganization frequency), and/or using a machine learning model, among other examples.

In some cases, for example, a BCI may be computed as a numerical value within a certain range or interval, such as a value in the range [0, 1] or [0, 100], such that the magnitude of the BCI is indicative of the level of criticality of the business application group. A criticality level may then be assigned to each business application group based on its computed BCI, such as a criticality level of LOW, MEDIUM, HIGH, or CRITICAL.

In some embodiments, for example, the criticality levels could be defined statically based on predetermined BCI ranges, such as the following:

Alternatively, the criticality levels could be determined dynamically, such as based on the statistical distribution of BCIs (e.g., statistical clustering) and/or using machine learning techniques. For example, the criticality levels could be defined using varying BCI ranges derived from the statistical distribution of BCIs for all business application groups, as shown inFIG. 6. In particular,FIG. 6illustrates an example600of the criticality levels assigned to various BCI ranges based on a hypothetical Gaussian distribution of BCIs for the respective business application groups.

As another example, the criticality levels could be dynamically determined using machine learning rather than a more “straightforward” calculation. For example, the object metrics311(and/or the BCIs or statistical distribution of BCIs computed from those metrics) could be supplied as input to a machine learning clustering algorithm (e.g., k-means clustering, mean-shift clustering), which partitions the business application groups into different clusters or tiers that each correspond to a particular criticality level. For example, based on the database object metrics311associated with the respective business application groups (e.g., hit ratio, copy frequency, reorganization frequency), a machine learning clustering algorithm may derive clusters of business applications and/or database objects that correspond to varying levels of business criticality. This approach is illustrated inFIG. 7, which shows a chart700depicting the criticality levels determined for a sample dataset using a machine learning clustering algorithm. For ease of illustration, a two-dimensional (2D) chart is shown, where the x-axis represents the maintenance frequency (which includes both copy frequency and reorganization frequency) and the y-axis represents the hit ratio. As shown in the illustrated example, four distinct clusters of business applications and/or database objects appear in the chart, which respectively correspond to criticality levels of LOW, MEDIUM, HIGH, and CRITICAL.

Further, in some embodiments, the criticality levels could be determined using a combination of the approaches described above (e.g., calculating probabilities and utilization of the percentiles and/or a density function(s)). Moreover, in varying embodiments, the criticality levels and/or BCIs may be computed at any desired level of granularity, such as for each business application group, each individual business application, and/or each individual database object. It should also be appreciated that the approaches described above are merely examples of how the criticality of business applications can be derived from database object metrics. Accordingly, in other embodiments, any suitable approach may be used to compute BCIs and/or determine criticality levels based on transaction metrics of database objects.

Turning back toFIG. 3, an example of the computed criticality data for business application groups 1-3 from object metrics table311is shown below in TABLE 3.

In the real world, however, there will typically be numerous database objects and related business application groups, so a more realistic example of the resulting criticality data313is illustrated inFIG. 3and also shown below in TABLE 4.

Once the criticality of the respective business application groups has been determined, the appropriate database maintenance tasks for the underlying database objects can then be set up, configured, and/or scheduled, as described further throughout this disclosure. Further, this process can be performed periodically using the latest object metrics to ensure that the criticality data for all business application groups is up to date (e.g., in the event the criticality level changes for any of the business application groups).

Further, throughout the ordinary course of business, it is common for new business application groups, business applications, and/or database objects to be deployed over time. When a new business application and/or database object314is initially deployed, however, the database object metrics required to reliably determine a criticality level using the approach described above may not be immediately available, as those metrics may not yet exist or may otherwise be incomplete. Accordingly, in some embodiments, machine learning (e.g., k-means clustering, mean-shift clustering) may be leveraged in order to predict the criticality of a newly launched business application group314(e.g., before its database object metrics have matured). For example, the object metrics311and corresponding criticality data313associated with the existing business application groups may serve as input to a machine learning algorithm316that trains a model to predict the criticality of new business application groups. In this manner, criticality data317(e.g., BCI and/or criticality level) for a new business application group314can initially be predicted by the trained machine learning model316based on the limited object metrics that are immediately available for its associated database objects315.

Moreover, in some embodiments, the predicted criticality317can subsequently be updated once the object315metrics for the new business application group314have matured to the point that a reliable criticality level can be computed at block312(e.g., after the metrics have been collected for some minimum or threshold amount of time).

FIG. 8illustrates an example800of using machine learning to predict the criticality of newly deployed objects, such as new business applications groups, new business applications, and/or new database objects. In the illustrated example, a machine learning scoring algorithm810is used to predict business criticality of new objects based on their similarities with existing objects. For example, the machine learning scoring algorithm810is first trained using data associated with the existing objects802, such as their corresponding object metrics (e.g., hit ratio, copy frequency, reorganization frequency) and criticality data (e.g., BCI and/or criticality level). Accordingly, when new object(s) are launched or deployed, their criticality (e.g., BCI and/or criticality level) can be predicted by applying the trained machine learning scoring algorithm810to the limited metrics804that are available for the new object(s). In some cases, for example, the limited metrics804for the new object(s) may still include a hit ratio, copy frequency, and reorganization frequency, but those metrics may be based on a very limited period of time. In other cases, some of those types of metrics may initially be altogether unavailable.

FIG. 9illustrates a flowchart900for an example embodiment of automatic database criticality detection. In some embodiments, flowchart900may be implemented using the embodiments and functionality described throughout this disclosure (e.g., computing system100ofFIG. 1and/or database criticality detection system200ofFIG. 2).

The flowchart may begin at block902by identifying one or more database object(s), such as a database table or index, that is associated with a computing application (or a group of computing applications) that is executable by one or more processors.

The flowchart may then proceed to block904to access a transaction history associated with the database object. For example, the transaction history may include transaction metrics associated with the database object (or alternatively may include data that can be used to derive transaction metrics), such as a hit ratio, copy frequency, reorganization frequency, and so forth.

The flowchart may then proceed to block906to determine a criticality level of the database object based on the transaction history.

In some embodiments, for example, a criticality index associated with a database object may be computed based on the transaction history, and then a criticality level may be determined based on the criticality index. The criticality level, for example, may be determined by: identifying a plurality of ranges corresponding to a plurality of criticality levels (e.g., low, medium, high, and critical), identifying the particular range that the criticality index falls within, and then identifying the criticality level corresponding to the identified range. Moreover, in some embodiments, the ranges corresponding to the respective criticality levels may be identified by identifying or computing criticality indexes associated with a plurality of database objects, identifying a statistical distribution of the criticality indexes, and determining the ranges based on the statistical distribution.

Alternatively, in some embodiments, the criticality level of the database object may be determined by: accessing a plurality of transaction histories associated with a plurality of database objects, partitioning the plurality of database objects into a plurality of clusters based on the plurality of transaction histories, assigning a plurality of criticality levels to the plurality of clusters, identifying the particular cluster that contains the database object of interest, and identifying the criticality level corresponding to that cluster. In some embodiments, for example, the database objects may be partitioned into clusters by applying a machine learning clustering model based on the transaction histories, and then identifying the clusters based on an output of the machine learning clustering model.

The flowchart may then proceed to block908to configure one or more database maintenance tasks for the database object(s) based on the determined criticality level, as described further throughout this disclosure.

Moreover, in some embodiments, the flowchart may also include functionality (not shown) for predicting the criticality of a new database object that is added to a database. For example, upon determining that a new database object has been added to the database, a partial transaction history associated with the new database object may be accessed, along with transaction histories and criticality data associated with existing database objects within the database. A predicted criticality level may then be determined for the new database object based on its partial transaction history along with the transaction histories and criticality data for the existing database objects. In some embodiments, for example, the predicted criticality level may be determined by: training a machine learning classification model based on the transaction histories and criticality data associated with the existing database objects; applying the machine learning classification model to the partial transaction history associated with the new database object; and determining the predicted criticality level of the new database object based on an output of the machine learning classification model. In this manner, one or more database maintenance tasks may then be configured for the new database object based on its predicted criticality level.

At this point, the flowchart may be complete. In some embodiments, however, the flowchart may restart and/or certain blocks may be repeated. For example, in some embodiments, the flowchart may restart at block902to continue determining the criticality level of database objects and/or computing applications.