WO2012054930A2

WO2012054930A2 - Centralized private network and database monitoring

Info

Publication number: WO2012054930A2
Application number: PCT/US2011/057531
Authority: WO
Inventors: Prakash Bhandari
Original assignee: Datavail Corporation
Priority date: 2010-10-22
Filing date: 2011-10-24
Publication date: 2012-04-26
Also published as: WO2012054930A3

Abstract

Systems and methods for a remote database administration (DBA) system that is external to or remote from a company site. The remote DBA system allows a team of database administrators to manage the database remotely via a DBA on-site module. The DBA on-site module accesses the database and collects data characterizing the health of the database. This data is then passed to the remote DBA system where the team of remote database administrators, or computer logic, analyzes the data, determines the health of the database, and initiates actions to manage the database health. The data is also used for trending that can provide capacity planning information. To avoid privacy concerns, the DBA on-site module converts data into metadata before transmitting metadata via a public network to the remote DBA system.

Description

CENTRALIZED PRIVATE NETWORK AND DATABASE MONITORING

CROSS-REFERENCE TO RELATED APPLICATIONS

This application claims priority to U.S. Provisional Application Serial No. 61/405,731, filed on October 22, 2010, and entitled "CENTRALIZED PRIVATE NETWORK AND DATABASE MONITORING," the entirety of which is hereby incorporated by reference.

FIELD OF INVENTION

The present disclosure is generally directed to database administration (DBA) and, more specifically, to administration of databases from a remote or off-site location. Certain aspects of the invention are applicable to remotely monitoring other systems.

BACKGROUND OF THE INVENTION

Databases are generally large sets of often persistent data generally associated with software for sorting and searching the data sets. Databases are generally administered by one to a handful of on-site database administrators. However, these on- site database administrators are difficult to replace at short notice, are often so consumed with urgent requests and tickets that upgrading or optimizing the database is impractical, and often have limited hours and limited experience.

SUMMARY OF THE INVENTION

The present disclosure describes systems and methods for remotely managing databases distributed between one or more computing systems. For instance, in one aspect, a remote database administrating system includes at least a receiving module, a health module, a procedures module, a data generation module, data analytics module and a transmission module. The receiving module is configured to receive communications including data (e.g., metadata) from a remote database administrating on-site module distributed among one or more computing systems that are remote from the remote database administrating system. The data may describe components, characteristics, data and/or operating parameters of a database distributed on the one or more computing systems and does so without reference to private data of the one or more computing systems. The health module is configured to apply rules to the data, or information derived from the metadata, in order to determine a health of the database. The procedures module is able to identify procedures to be executed on the monitored databases based on the health of the database for use in managing the health of the database (e.g., via one or more computing systems). The data generation module is operable to generate procedural data (which may include metadata) for transmission to the database administrating on-site module. The procedural data enables the database administrating on-site module to instruct the one or more computing systems to carry out the procedures in managing the health of the database. The transmission module transmits the procedure data to the remote database administrating on-site module.

In one arrangement, the system may include a rules database accessible by the health module. For instance, the rules database may include a first set of rules associated with a first database and a second set of rules associated with a second database. In some situations, the first and second sets of rules may share at least one common rule. The data may include metadata that is substantially free of private data of the one or more computing systems. For instance, the data could include at least one of a server name, a computer name, a user name, a host name, a password and an IP address. In one arrangement, one of the procedures may include at least one of moving at least a portion of the database to a different computing system and adding an additional data file for use by the database on one of the computing systems. For instance, the different computing system may include one of the computing systems that has accessed the database more recently than another of the computing systems. In one arrangement, the transmission module may transmit event notifications and database health reports to the on-site module.

In another aspect, an on-site module is operative to facilitate secure off-site database management. Specifically, a computer module is configured to access data from one or more computing systems, wherein the data characterizes a health of a database distributed between the one or more computing systems. The computer module is also configured to convert the data to metadata, wherein the metadata is free from private data from the database. The computer module is further configured to transmit the metadata to a remote database administrating system. The computer module is also configured to receive procedure data from the remote database administrating system and interpret any metadata therein. Lastly, the computer module is configured to carry out procedures to manage the health of the database based on the procedure data.

Another aspect of the disclosure involves an off-site process for remote database management. The process includes receiving metadata from a database administrating on-site module distributed between one or more remote computing systems; analyzing the metadata to determine a health of a database distributed between the one or more remote computing systems, wherein the analyzing is performed in light of rules corresponding to the database; identifying procedures to manage the health of the database, where the procedures are identified based on the health of the database; and instructing the remote database administrating on-site module to carry out the procedures. A corresponding system involves a receiving module, a database health monitoring module, and a management module. The receiving module receives metadata from a remote administrating on-site module. The database health monitoring module determines a health of a database by analyzing the metadata or information derived from the metadata. The management module maintains and improves the health of the database via the remote database administrating on-site module.

BRIEF DESCRIPTION OF THE DRAWINGS

For a more complete understanding of the present invention and further advantages thereof, reference is now made to the following detailed description taken in conjunction with the drawings in which:

Figure 1 illustrates a remote database administration (DBA) system managing databases at three company sites via a public network.

Figure 2 illustrates a detailed embodiment of a remote DBA system.

Figure 3 illustrates a detailed embodiment of a remote DBA system managing the health of a database via a DBA on-site module.

Figure 4 illustrates a method for managing a remote database.

DETAILED DESCRIPTION

This disclosure involves the administration of one or more databases and, in particular, describes the process of remotely monitoring and managing database health. Database health can encompass a number of different aspects, including performance, security, stability, memory usage, usage expansion, backup and recovery, reporting, and access assurance, to name a few. Monitoring database health can include, among other things, monitoring for declines in health, potential future declines in health, and areas where health can be improved via database optimization. Managing database health can include maintenance, corrective action to rectify declines in health, preventative action to prevent potential future declines in health, database optimization, and reporting, among others. Monitoring and managing can be carried out by one or more dedicated on-site database administrators. However, on-site database administrators are often expensive or work limited hours, and may have less expertise than a larger team of database administrators. To overcome these limitations, a remote team of database administrators can replace or supplement on-site database administrators, or a remote automated system. This can result in monitoring and management at lower costs, at all times of day and night throughout the year, and expanded expertise.

Yet, remote DBA presents another set of challenges. First, remote access may tax computing resources of the computing systems between which the database is distributed. Second, remote access raises the risk that private data transmitted offsite to the remote database administrators will be stolen, illegally accessed, or accidentally made public. To avoid these problems, the present disclosure describes systems and methods for a remote DBA system that is external to or remote from a database site. The remote DBA system allows a team of database administrators to manage the database remotely via a DBA on-site module that works in conjunction with system components at the off-site location. The DBA on-site module may be distributed between computing systems at a company's site or sites (and possibly computing systems networked into the company site). The DBA on-site module also accesses the database and collects data characterizing the health of the database. This data is then passed to the remote DBA system where the team of remote database administrators, or an automated version of the remote DBA system, can analyze the data, determine the health of the database, and initiate actions to manage the database health. Some of this analysis and action initiation may be automated. The remote DBA system in communication with a DBA on-site module enables remote database management to primarily use computing resources on the remote DBA system such that there is minimal impact to the on-site system of the customer.

Furthermore, to avoid privacy concerns the DBA on-site module can convert data from the database, and the computing systems that the database is distributed between, into metadata before transmitting metadata via a public network to the remote DBA system. For example, specific data to be protected, certain categories of data, or substantially all customer data may be converted into a metadata representation before transmission. The noted metadata is generally a representation of data that describes characteristics of the database and computing systems that the database is distributed on, but does so without reference to private data. Non-limiting examples of private data include names of servers and computers, IP addresses, names of users, and passwords, to name a few. Metadata for the name of a server, "Matrix 1," could be any corresponding information, string or token that identifies the server, for example, "Customer_20245_Server_90." As such, when the DBA on-site module communicates or transmits metadata to the DBA system, private data is not transmitted through the public network. There is also substantially no risk of disclosure at the remote DBA system since the metadata does not contain any references to private data that can be accessed by unauthorized persons or systems. Thus, there is no substantial risk of disclosure of private data.

Figure 1 illustrates a remote DBA system managing databases at three company sites via a public network. Each of a number of company sites 110, 120, 130 may include one or more databases 114, 124, 134 distributed between multiple computing systems 118, 128, 138. Although not illustrated, at least some portions of databases 114, 124, 134 may be distributed between them and on-site and offsite computing systems 118, 128, 138. For example, mobile phones, laptop computers used at coffee shops or offsite locations, and home computers networked into the on-site networks, to name a few, can be offsite yet have one or more databases distributed between them.

In any event, a remote DBA system 100 monitors the databases 114, 124, 134 via one or more DBA on-site modules 112, 122, 132 that are distributed between computing systems 118, 128, 138 at each company site 110, 120, 130. Each on-site module 112, 122, 132 is generally operable to access data from the one or more databases 114, 124, 134 and pass such data to the remote DBA system 100 which may use the data to characterize a health of the databases 114, 124, 134. The DBA on-site modules 112, 122, 132 and the remote DBA system 100 may communicate via a public network 150 such as the Internet (although other embodiments envision that the DBA on-site modules 112, 122 132 and the remote DBA system 100 may additionally or alternatively communicate via one or more private networks). There are no restrictions on who can access the public network 150.

The DBA on-site modules 112, 122, 132 can include hardware, software, firmware, or combinations thereof. For instance, the DBA on-site module 112 in company site 110 may be distributed between the computing systems 118. In company site 120, the DBA on-site module 122 is in communication with the computing systems 128 via the company's private network 126. A private network is only accessible to authorized users. In company site 130, the DBA on-site module 132 is in communication with computing systems 138 via the company's private network 136 within a firewall 142 and in communication with computing systems 148 via the company's private network 136 through the firewall 142. Other DBA on-site module distributions, locations, configurations, and communication paths are also envisioned. In many cases, the customer location will be defined by systems that operate within a firewall (or other secured environment) regardless of the physical locations of those systems, as opposed to being defined by a specific geographical location.

Figure 2 illustrates a detailed embodiment of a remote DBA system (e.g., remote DBA system 100 of Figure 1). In the illustration, only one company site 220 is illustrated, although it should be understood that the remote DBA system 200 can manage a plurality of databases 224 at a plurality of company sites 220. In the illustrated embodiment, the remote DBA system 200 includes a receiving module 202, a database health monitoring module 204, and a management module 206. The receiving module 202 receives communications including metadata from the DBA on-site module 222 via the public network 250. Such metadata may describe the database 224 and the computing systems 228, as well as characteristics and operating parameters thereof, without using private data.

The database health monitoring module 204 then analyzes the communications using the metadata and determines or otherwise characterizes a health of the database 224. Analyzing the metadata can also be done using rules associated with the database 224. A detailed discussion of such rules is provided below in connection with Figure 3.

Based on the database 224 health, the management module 206 can assist in maintaining and improving the health of the database 224 via the DBA on-site module 222. This can be accomplished, for example, by identifying potential future problems or critical conditions and generating reports or alerts, or by taking action to prevent future problems. For instance, the management module 206 may identify one of the three computing systems 228 that is nearing full memory capacity and thus has the potential to cause database 224 read/write errors or slow performance. Maintaining database 224 health may also include security monitoring, performance management, memory usage optimization, growth tracking and prediction, backup status monitoring, reporting, and access assurance, to name a few. For example, a database 224 that is stored on memory that is near full capacity can be partially moved, as controlled by the management module 206, to a computing system 228 with more available memory. The management module 206 can also maintain health of the database 224 by identifying current problems and taking action to correct the current problems. Once a current problem is resolved, the management module 206 can analyze the causes of the problem and take preventative measures to prevent reoccurrence of the problem. The management module 206 can thus improve the health of the database 224 by optimizing performance of the database 224. The management module 206 can also provide reporting services to the company. For instance, it can transmit event notifications following important events (e.g., database errors, completed security scans, database upgrades). It can also transmit database health reports. A database health report can describe health of the database 224 including performance, security, and resource utilization, among others. Database health reports can also be stored on a server accessible via the public network 250 (e.g., viewing the reports via a website). Database information that is aggregated across multiple customers, databases, and/or operating system versions can be published to MICROSOFT® SHAREPOINT and/or social networking sites.

Before any customer private information is passed back over public network 250 to the remote DBA on-site module 222 and/or computing systems 228, the remote DBA system 200 may obfuscate the customer private information on databases and servers that it is monitoring. In the illustrated embodiment, the DBA on-site module 222 and the remote DBA system 200 communicate via the public network 250. The DBA on- site module 222 can be distributed between the computing systems 228 or can communicate with them via an optional private network 226. Via the optional private network 226, the DBA on-site module 222 can also connect to the public network 250.

Figure 3 illustrates another detailed embodiment of a remote DBA system 300 (e.g., the remote DBA system 100 of Figure 1) managing the health of a database (e.g., one or more of databases 114, 124, 134 of Figure 1) via a DBA on-site module (e.g., one or more of DBA on-site modules 112, 122, 132). The remote DBA system 300 is configured to allow a team of database administrators located at one or more remote facilities, to, via a public network 350 (e.g., the Internet), monitor, and/or manage the database 320. For instance, a single remote DBA system 300 in Broomfield, Colorado, can provide a team of database administrators with access to databases 320 located and distributed throughout the country. As such, this remote team can perform the same if not more database administration tasks than a collection of on-site administrators at each site where a database 320 resides. Although this disclosure often refers to the team of remote administrators, in some cases the remote DBA system can automatically carry out some functions of the remote administrators, or be completely automated.

The company site 334 may include a plurality of computing systems such as, for instance, personal computers 324, servers 322 and/or mobile devices 326. Personal computers 324 generally, but not always, include a user interface, a processor, memory, and a connection to a network. Servers 322 generally, but not always, include a processor and memory, and share these resources with other computers via a network. Mobile devices 326 generally, but not always, include a user interface, processor, and memory. Other combinations of these and other features can also fall under the category of computing systems. For the purposes of this disclosure, computing systems may include personal computers, servers, mainframes, mobile computing devices (e.g., smart phones, electronic book readers), devices having a processor and memory storage, and devices having at least a processor and network connection. A computing system may include a display, keyboard, mouse, touchpad, speakers, microphone, printer, CD and/or DVD drive, wireless connectivity, and other features known in the art or those that become common to computing systems in the future.

These computing systems 322, 324, 326 can reside at one or more sites 334

(although only a single site 334 is illustrated in Figure 3). In an embodiment, some computing systems 322, 324, 326 can reside off-site but be networked into the on-site computing systems 322, 324, 326. For instance, the server 322 and personal computer 324 can reside at one site 334 while the mobile device 326 travels with an employee off- site. In another example, some computers 324 can be on-site while other computers 324 are employee's home computers or computers carried between work and a home office. In one embodiment, the site 334 includes all computing systems 322, 324, 326 within a firewall 360 regardless of where the computing systems 322, 324, 326 are physically located. In all of these non-limiting examples, the computing systems 322, 324, 326 are networked together either via private or public networks. Thus, the remote DBA system 300 can access the computing systems 322, 324, 326 regardless of a location of the computing systems 322, 324, 326 (e.g., via the DBA on-site module 330). In alternative embodiments, a company may have multiple private networks 328, utilize a combination of private networks 328 and the public network 350, and/or have multiple sites 334. The private network 328 can include, for instance, a plurality of networked computers/servers/databases and/or remote computing devices (e.g., off-site computers/servers, smart phones, MP3 players, and netbooks, to name a few). An intranet is a non- limiting example of a private network 328.

One or more databases 320 may be distributed between one or more computing systems 322, 324, 326. For instance, a database 320 of sales receipts can be distributed between servers 322 in a variety of locations as well as between computers 324 (e.g., cash registers) located at various retail facilities. In another example, a database 320 of customer contact information and purchase history can be distributed between the mobile devices 326 of sales associates. Such a database 320 could also be distributed between the mobile devices 326 of sales associates and servers 322 and computers 324 at a variety of office sites 334. In some cases a database 320 may be distributed on a first computing system or set of computing systems. A second computing system or set of computing systems may access the database 320 without the database 320 being distributed on the second computing system or set of computing systems.

A DBA on-site module 330 may be distributed between one or more of the computing systems 322, 324, 326 for use in collecting and passing data (e.g., metric data) to remote DBA system 300 and thereafter receiving reports and/or instructions from the remote DBA system 300 to maintain the health of the database 320 and/or computing systems 322, 324, 326. To minimize private network 328 resources used by the DBA on-site module 330, the bulk of processing associated with database management may be performed at the remote DBA system 300. In this regard, the DBA on-site module 330 may thus act as a conduit for the remote DBA system 300 to manage the database 320. In one embodiment, the DBA on-site module 330 can provide access to the computing systems 322, 324, 326 via the optional private network 328, although such access need not go through the private network 328 (nor does a private network 328 need to exist). To monitor database health, the illustrated DBA on-site module 330 may access data on the one or more computing systems 322, 324, 326 and then communicate the data over the public network 350 to the remote DBA system 300. To avoid transmitting protected private data, the DBA on-site module 330 may identify and convert the data to metadata 332 before transmitting the metadata 332 to the remote DBA system 300. Metadata 332 is a representation of the data that has been converted such that private data cannot be easily deciphered. For instance, data may include a server name, "joey_bourges_44." Since "joey_bourges" may be private information, the server name can be converted to the following metadata, "customer26_ServerNo_3."

In any event, such communications can either take place on a periodic basis, randomly, or at the request of the remote DBA system 300 or the DBA on-site module 330 or the private network 328. These communications can also be dictated by the bandwidth needs of the optional private network 328. For instance, these communications may only take place when the computing systems 322, 324, 326 are using less than the maximum bandwidth to the public network 350.

In one embodiment, the DBA on-site module 330 can be a computing system, a set of computing systems, hardware residing on one or more computing systems, software running on one or more computing systems, or a combination of software and hardware. Furthermore, the private network 328 can include an optional firewall 360. The firewall 360 regulates all communications that pass through it. For instance, the firewall 360 controls what communications pass between the public and private networks 350, 328. The firewall 360 can be a computing system, a set of computing systems, hardware residing on one or more computing systems, software running on one or more computing systems, or a combination of software and hardware. The firewall 360 only allows authorized communications to pass through it.

The remote DBA system 300 generally monitors the health of the database 320 by receiving and analyzing communications (e.g., including metadata 332) transmitted from the DBA on-site module 330 and analyzing and characterizing the health of the database 320. It is noted that some of the data to be analyzed may be provided in the form of metadata representations and other data may not. For instance, the metadata may be analyzed in the form received from the DBA on-site module 330 and/or may be converted into regular data (e.g., using any appropriate description process). In the latter regard, it may be desired to convert any resulting data (e.g., in the form of reports or alerts) back into metadata before transmission back to the site 334 or other location. For instance, analyzing metadata 332 may allow the remote DBA system 300 to determine what percentage of long-term memory (e.g., a hard drive) is being used on the computing systems 322, 324, 326 that the database 320 is distributed between. Having appropriately characterized the health of the database 320, the remote DBA system 300 can then determine what actions should be carried out in order to manage the health of the database 320. For instance, in the event that the remote DBA system 300 ascertains that some computing systems 326 are running out of available free space, the remote DBA system 300 may determine that additional data files should be added to the database 320 to correct the impending problem.

Once actions to be carried out have been determined, the remote DBA system 300 generates corresponding data or instructions to be transmitted to the DBA on-site module 330 which may then be downloaded by the DBA on-site module 330. The DBA on-site module 330 can provide information and/or carry out operations to manage database 320 health based on the data or instructions. In the alternative, the DBA on- site module 330 can instruct the computing systems 322, 324, 326 or personnel to take actions to manage database 320 health based on the data or instructions. The DBA on- site module 330 continues to monitor data (e.g., even after any actions or instructions have been carried out) for use in continued health monitoring of database 320 and then provides the remote DBA system 300 with information that it can use to analyze the results of the last set of management operations.

In one embodiment, the remote DBA system 300 includes one or more modules configured to carry out the functionality described above. In one implementation, the modules comprise software programmed to perform one or more specific functions. It will be appreciated that the modules are thus executed by one or more processing platforms. The logic may alternatively be embodied at least in part in hardware and/or firmware. For instance, a module can include code for execution on any appropriate computing system.

In the illustrated embodiment, the remote DBA system 300 may include a communication module 316, a health module 304, a procedures module 306, a data generation module 308, an analytics module 309, and/or a rules database 312. The communication module 316 may be in communication with the DBA on-site module 330 via public network 350 and may include a receiving module 302 that is configured to receive communications including metadata 332 from the DBA on-site module 330. As discussed above, the metadata 332 may be indicative of characteristics of the database 320 (e.g., server names and locations, types of connections between computers, bandwidth limitations, processing and memory capabilities of computers and servers, types of data and processes associated with computers and servers, to name a few) and may be devoid of or at least limited in the quantity of certain private data of the database 320 or computing systems 322, 324, 326 (e.g., such as server names) that it discloses. In an embodiment, the receiving module 302 includes logic for identifying incoming communications, analyzing the communications to identify the source site, parsing the communications to obtain various fields of data and, optionally, identifying and decoding metadata.

The health module 304 is generally operable to apply rules 314 to the data extracted from the communication including metadata 332 in order to characterize a health of the database 320. Rules 314 are associated with the database 320, and different rules 314 or sets of rules 314 can be associated with different databases. At the same time, one or more rules 314 may be common to two or more databases even when not owned by the same company. The rules 314 enable the health module 304 to characterize the health of the database 320 based on analysis of the metadata 332. In one arrangement, the rules 314 can indicate health thresholds to assist the remote DBA system 300 in characterizing the health of the database 320. For instance, a rule 314 associated with the database 320 could indicate that the database 320 is optimally accessed when distributed among no more than fifty computing systems 322, 324, 326 at a time. If the database 320 is distributed between more than fifty computing systems, then the procedure module 306 may determine that portions of the database 320 residing on computing systems that have not modified or accessed the database 320 for a significant time are to be moved to one of the fifty computing systems that have modified or accessed the database 320 more recently. Similarly, another database may be associated with a similar rule 314 establishing a forty computing system threshold rather than a fifty computing system threshold. These are just two exemplary and non- limiting examples of rules 314.

Rules 314 can also indicate how the remote DBA system 300 is to interpret and analyze the metadata 332 and can assist the remote DBA system 300 in generating data and instructions for transmission to the DBA on-site module 330 (e.g., for use in taking corrective action(s)). For instance, rules 314 may indicate how often the remote DBA system 300 communicates with the DBA on-site module 330, and/or identify particular metadata 332 that the remote DBA system 300 should monitor for. Rules 314 may be associated with particular database management procedures associated with different metadata 332 or different types of metadata 332. The remote DBA system 300 can use rules 314 to identify procedures operable to restore, maintain or improve the health of the database 320. These are just some of the ways in which rules 314 can be used.

Rules 314 may be contained in at least one rules database 312 and can individually or in sets correspond to different databases 320. In some instances, one or more rules 314 can correspond to more than one databases 320. Rules 314 can be updated. For instance, as a private network 328 increases hardware performance or increases the number of computing systems 322, 324, 326 on the private network 328, the rules 314 corresponding to databases 320 distributed between those computing systems 322, 324, 326 may be updated accordingly. Rules 314 can also be added to the rules database 312. For instance, when the remote DBA system 300 becomes responsible for a new database, new rules 314 may be added that correspond with the new database.

In one arrangement, database health can include performance. For instance, read/write time and percent read/write errors are two non-limiting examples of database performance characteristics. The potential for future performance declines can also be considered to be database health. For instance, the potential for crashes and bandwidth overload are two non-limiting examples of potential future performance declines that can be considered part of database health. Hence, health of the database can depend upon current performance as well as predicted future performance. Health can also include security monitoring, memory usage optimization, growth tracking and prediction, backup and recovery status and times, query run times, reporting, and access assurance, to name a few.

The remote DBA system 300 also can provide better analytics than an on-site DBA or team of on-site DBA's. This is because the remote DBA system 300 analyzes a large number of databases and thus deals with far more problems than any single DBA or team of DBA's ever sees. Based on this history of analyzing and fixing problems, the remote DBA system 300 can develop analytic tools and/or rules 314 to monitor databases and recognize problems and potential future problems. For instance, the optional analytics module 309 may be configured to store data describing problems and system health trends, analyze the data and trends, and develop rules 314 and procedures that the remote DBA system 300 can use to monitor and manage databases. The analytics module 309 can also generate or assist the remote team of DBA's in developing tools or software that can be used by the DBA system 300 or that can be remotely installed on computing systems 322, 324, 326 of customers to prevent and correct problems on customer computing systems 322, 324, 326. The trend data generated by rules 314 can also be published to social networking sites to provide information about large numbers of monitored targets (e.g., after removing customer sp ecific information) .

The procedures module 306 may be generally operable to identify actionable procedures for managing the health of the database 320 (e.g., corrective actions, preventative measures, etc) based on the (current or future) health of the database 320. The procedures can be directed to maintenance of the database health, corrective action to rectify database health declines, preventative action to prevent future declines in database health, database optimization, and/or the like. Procedures can also include instructions for reporting to be carried out by either the DBA on-site module 330 or the remote DBA system 300.

In order for the procedures to be carried out, the data generation module 308 generates procedural data to be transmitted to the DBA on-site module 330. The procedure data enables the DBA on-site module 330 to carry out the procedures in maintaining and correcting database 320 health, preventing future health declines, optimizing the database 320, and reporting.

The communication module 316 may also include a transmission module 310 that is configured to transmit the procedure data to the DBA on-site module 330. Transmissions can take place periodically or at the discretion of the remote DBA system 300 or the computing systems 322, 324, 326 between which the database 320 is distributed.

The remote DBA system 300 may also be configured to prioritize analysis of metadata 332 or the carrying out of management tasks. For instance, the order in which metadata 332 is analyzed can be prioritized if there is more metadata 332 than the remote DBA system 300 can analyze in parallel. The rules 314 can be used to determine a priority. For instance, a rule 314 may indicate that metadata 332 associated with one company is to be analyzed before metadata 332 associated with a second company. In another example, a rule 314 may indicate that metadata 332 relating to current problems is to be analyzed before metadata 332 relating to potential future problems. Similarly, rules 314 can dictate an order in which procedures are carried out after metadata 332 has been analyzed. For example, a rule 314 may indicate that taking preventative action after a current problem has been corrected should be carried out before optimization of a database 320.

The public network 350 can establish communication between a single private network 328 and the remote DBA system 300 or between a plurality of private networks 328 and the remote DBA system 300. Multiple public networks 350 can establish communication between a plurality of private networks 328 and the remote DBA system 300. Communications over the public network 350 can be time multiplexed. Both the public and private networks 350, 328 can be hardwired, wireless, or a combination of the two. Although the public network 350 has been described as the communications means between the DBA on-site module 330 and the remote DBA system 300, in one embodiment, the public network 350 may in some embodiments be replaced with a private network 328. For instance, the remote DBA system 300 could be part of the private network 328 but continue to communicate with the computing systems 322, 324, 326 via the DBA on-site module 330. In one embodiment, the remote DBA system 300 can be included within a trusted site-to-site virtual private network (VPN) or within a firewall 360. In another embodiment, the remote DBA system 300 may access the DBA on-site module 330 partially through a private network 328 and partially through a public network 350.

Figure 4 illustrates a method for managing a remote database. Managing may involve monitoring the health of the remote database, maintaining the health of the remote database and/or improving or restoring the health of the remote database. Although this method 400 is directed towards management of a single remote database, application to a plurality of remote databases is also envisioned. The method 400 may include receiving (402) metadata from a DBA on-site module distributed between one or more remote computing systems. The metadata can be generated by the DBA on-site module as a representation of data from the remote database. The method 400 may include analyzing (404) the metadata to determine a health of the remote database via operation 404. For instance, the analyzing can be performed using one or more rules corresponding to the remote database. Thus, even if metadata for two different remote databases is analyzed, the results may differ if different rules correspond to the two different remote databases. The method 400 may also include identifying (406) procedures to manage the health of the remote database. The procedures may be identified based on the health of the remote database. Finally, the method 400 may include instructing (408) the DBA on-site module to carry out the procedures.

It will be readily appreciated that many deviations may be made from the specific embodiments disclosed in the specification without departing from the spirit and scope of the invention. In one arrangement, the utilities disclosed herein may be in relation to one or more past or future time periods. Also, it should be understood that the functionalities performed by many of the processes and modules discussed herein may be performed by other modules, devices, processes, etc. The illustrations and discussion herein has only been provided to assist the reader in understanding the various aspects of the present disclosure. Furthermore, one or more various combinations of the above discussed arrangements and embodiments are also envisioned.

Embodiments disclosed herein can be implemented as one or more computer program products, i.e., one or more modules of computer program instructions encoded on a computer-readable medium for execution by, or to control the operation of, data processing apparatus. For example, the various components of the remote DBA system 300 (e.g., communication module 316, health module 304, etc.) may be provided in such computer-readable medium and executed by a processor or the like. The computer-readable medium can be a machine-readable storage device, a machine- readable storage substrate, a memory device, a composition of matter affecting a machine-readable propagated signal, or a combination of one or more of them. The various systems and modules shown in Figures 1-3 may encompass one or more apparatuses, devices, and machines for processing data, including by way of example a programmable processor, a computer, or multiple processors or computers. In addition to hardware, there may be code that creates an execution environment for the computer program in question, e.g., code that constitutes processor firmware, a protocol stack, a database management system, an operating system, or a combination of one or more of them. A computer program (also known as a program, software, software application, script, or code) used to provide the functionality described herein (e.g., the dynamic consumption cost determination and associated resource scheduling disclosed herein) can be written in any form of programming language, including compiled or interpreted languages, and it can be deployed in any form, including as a stand-alone program or as a module, component, subroutine, or other unit suitable for use in a computing environment. A computer program does not necessarily correspond to a file in a file system. A program can be stored in a portion of a file that holds other programs or data (e.g., one or more scripts stored in a markup language document), in a single file dedicated to the program in question, or in multiple coordinated files (e.g., files that store one or more modules, sub-programs, or portions of code). A computer program can be deployed to be executed on one computer or on multiple computers that are located at one site or distributed across multiple sites and interconnected by a communication network.

The processes and logic flows described in this specification can be performed by one or more programmable processors executing one or more computer programs to perform functions by operating on input data and generating output. The processes and logic flows can also be performed by, and apparatus can also be implemented as, special purpose logic circuitry, e.g., an FPGA (field programmable gate array) or an ASIC (application- specific integrated circuit). Processors suitable for the execution of a computer program may include, by way of example, both general and special purpose microprocessors, and any one or more processors of any kind of digital computer. Generally, a processor will receive instructions and data from a read-only memory or a random access memory or both. Generally, the elements of a computer are one or more processors for performing instructions and one or more memory devices for storing instructions and data. The techniques described herein may be implemented by a computer system configured to provide the functionality described.

In different embodiments, the modules and systems disclosed herein may include one or more of various types of devices, including, but not limited to a personal computer system, desktop computer, laptop, notebook, or netbook computer, mainframe computer system, handheld computer, workstation, network computer, application server, storage device, a consumer electronics device such as a camera, camcorder, set top box, mobile device, video game console, handheld video game device, a peripheral device such as a switch, modem, router, or, in general, any type of computing or electronic device.

Typically, a computer will also include, or be operatively coupled to receive data from or transfer data to, or both, one or more mass storage devices for storing data, e.g., magnetic, magneto-optical disks, or optical disks. However, a computer need not have such devices. Moreover, a computer can be embedded in another device, e.g., a mobile telephone, a personal digital assistant (PDA), a mobile audio player, a Global Positioning System (GPS) receiver, a digital camera, to name just a few. Computer- readable media suitable for storing computer program instructions and data include all forms of non- volatile memory, media and memory devices, including by way of example semiconductor memory devices, e.g., EPROM, EEPROM, and flash memory devices; magnetic disks, e.g., internal hard disks or removable disks; magneto-optical disks; and CD-ROM and DVD-ROM disks. The processor and the memory can be supplemented by, or incorporated in, special purpose logic circuitry. To provide for interaction with a user, embodiments of the subject matter described in this specification can be implemented on a computer having a display device, e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor, for displaying information to the user and a keyboard and a pointing device, e.g., a mouse or a trackball, by which the user can provide input to the computer. Other kinds of devices can be used to provide for interaction with a user as well; for example, feedback provided to the user can be any form of sensory feedback, e.g., visual feedback, auditory feedback, or tactile feedback; and input from the user can be received in any form, including acoustic, speech, or tactile input.

While this disclosure contains many specifics, these should not be construed as limitations on the scope of the disclosure or of what may be claimed, but rather as descriptions of features specific to particular embodiments of the disclosure. Certain features that are described in this specification in the context of separate embodiments can also be implemented in combination in a single embodiment. Conversely, various features that are described in the context of a single embodiment can also be implemented in multiple embodiments separately or in any suitable subcombination. Moreover, although features may be described above as acting in certain combinations and even initially claimed as such, one or more features from a claimed combination can in some cases be excised from the combination, and the claimed combination may be directed to a subcombination or variation of a subcombination.

Similarly, while operations are depicted in the drawings in a particular order, this should not be understood as requiring that such operations be performed in the particular order shown or in sequential order, or that all illustrated operations be performed, to achieve desirable results. In certain circumstances, multitasking and/or parallel processing may be advantageous. Moreover, the separation of various system components in the embodiments described above should not be understood as requiring such separation in all embodiments, and it should be understood that the described program components and systems can generally be integrated together in a single software and/or hardware product or packaged into multiple software and/or hardware products.

The foregoing description of the present invention has been presented for purposes of illustration and description. Furthermore, the description is not intended to limit the invention to the form disclosed herein. Consequently, variations and modifications commensurate with the above teachings, and skill and knowledge of the relevant art, are within the scope of the present invention. The embodiments described hereinabove are further intended to explain best modes known of practicing the invention and to enable others skilled in the art to utilize the invention in such, or other embodiments and with various modifications required by the particular application(s) or use(s) of the present invention. It is intended that the appended claims be construed to include alternative embodiments to the extent permitted by the prior art.

Claims

CLAIMS What is claimed:

1. A remote database administrating system, comprising:

a receiving module configured to receive data from a database administrating on-site module distributed among one or more computing systems that are remote from the database administrating system, wherein the data describes characteristics of a database distributed on the one or more computing systems;

a health module configured to apply rules to the data to determine a health of the database;

a procedures module configured to identify procedures based on the health of the database, wherein the procedures, when carried out by the one or more computing systems, are operable to manage the health of the database;

a data generation module configured to generate procedural data corresponding to one or more the procedures for transmission to the database administrating on-site module, wherein the procedure data enables the database administrating on-site module to instruct the one or more computing systems to carry out the procedures in managing the health of the database; and

a transmission module configured to transmit the procedural data to the database administrating on-site module.

2. The remote database administrating system of Claim 1, further comprising a rules database accessible by the health module, wherein the rules database comprises a plurality of rules, and wherein one or more of the plurality of rules are associated with the database.

3. The remote database administrating system of Claim 2, wherein the plurality of rules comprises a first set of rules associated with a first database and a second set of rules associated with a second database.

4. The remote database administrating system of Claim 3, wherein the first and second sets of rules share at least one common rule.

5. The remote database administrating system of Claim 1 , wherein the data comprises metadata that is substantially free of private data of the one or more computing systems.

6. The remote database administrating system of Claim 5, wherein the data comprises at least one of a server name, a computer name, a user name, a host name, a password and an IP address.

7. The remote database administrating system of Claim 1, wherein one of the procedures comprises at least one of moving at least a portion of the database to a different computing system and adding an additional data file for use by the database on one of the computing systems.

8. The remote database administrating system of Claim 7, wherein the different computing system comprises one of the computing systems that has accessed the database more recently than another of the computing systems.

9. The remote database administrating system of Claim 1, wherein the computing systems are part of a private network.

10. The remote database administrating system of Claim 1, wherein a firewall precludes unauthorized communications between the private network and the public network.

11. The remote database administrating system of Claim 1, wherein the transmission module is further configured to transmit event notifications and database health reports.

12. The remote database administrating system of Claim 1, wherein the procedures are configured to limit future decline in database health.

13. The remote database administrating system of Claim 1, wherein the procedures are configured to correct a decline in database health.

14. The remote database administrating system of Claim 13, wherein the procedures are configured to limit the decline in database health from reoccurring.

15. The remote database administrating system of Claim 1, wherein the procedures are configured to improve the health of the database by optimizing database performance.

16. The remote database administrating system of Claim 1, wherein the computing systems carry out operations in response to the procedures received by the remote database administrating on-site module.

17. A computer module configured to :

access data from one or more computing systems, wherein the data characterizes a health of a database distributed between the one or more computing systems;

convert the data to metadata, wherein the metadata is free from private data from the database;

transmit the metadata to a remote database administrating system;

receive procedure data from the remote database administrating system; and carry out procedures to manage the health of the database based on the procedure data.

18. The computer module of Claim 17, wherein the computer module is further configured to carry out procedures to maintain or improve the health of the private network.

19. The computer module of Claim 17, wherein the data comprises at least one of a server name, a computer name, a user name, a host name, a password, and an IP address,

20. The computer module of Claim 17, wherein the metadata comprises information that allows the remote database administering system to obtain the data.

21. The computer module of Claim 20, wherein the information allows for decryption of the metadata.

22. The computer module of Claim 17, wherein the carried-out procedures comprise instructions for the computing systems to use in managing the health of the database.

23. A method of managing a remote database, the method comprising:

receiving metadata from a remote database administrating on-site module that distributed between one or more remote computing systems;

analyzing the metadata to determine a health of the remote database, wherein the analyzing is performed in light of rules corresponding to the remote database;

identifying procedures to manage the health of the database, wherein the procedures are identified based on the determined health of the database; and

instructing the remote database administrating on-site module to carry out the procedures.

24. The method of Claim 23, wherein the rules correspond to the remote private network.

25. The method of Claim 23, wherein the procedures to manage comprise procedures to maintain or improve the health of the remote database.

26. A system, comprising:

a receiving module configured to receive metadata from a database administrating on-site module;

a database health monitoring module configured to determine a health of a database by analyzing the metadata; and

a management module configured to maintain and improve the health of the database via the database administrating on-site module.

27. The system of Claim 26, wherein the management module is further configured to transmit event notifications and database health reports.

28. The system of Claim 26, wherein the database health monitoring module uses rules associated with the database along with the metadata to determine the health of the database.

29. The system of Claim 26, wherein metadata describes the database without using private data.

30. The system of Claim 26, wherein the management module maintains the health of the database by identifying a potential future problem and taking action to prevent the potential future problem.

31. The system of Claim 26, wherein the management module maintains the health of the database by identifying a current problem and taking action to correct the current problem.

32. The system of Claim 31, wherein the management module maintains the health of the database by taking preventative measures to prevent the current problem from reoccurring.

33. The system of Claim 26, wherein the management module improves the health of the database by optimizing database performance.