Sap Se

Chul Won Lee

Juchang Lee

Kyu Hwan Kim

Myunggon Park

Jeong Hee Won

Ki Hong Kim

Jaeyoung Choi

Nosub Sung

Beomsoo Kim

Min Ji Yoon

Wonyoung Kwak

Sunyoung Han

Young Hun Kim

Jongheon Park

Norman May

Chang Gyoo Park

Sang Kyun Cha

Daniel Booss

Sung Heun Wi

Werner Thesing

Hui Feng

Ye Fan

Yong Wook Jeong

Ian McHardy

Abhishek Singhi

Jeff Albion

Guanghui Qiu

Rich Jones

Eunjin Song

Christian Bensberg

Di Wu

Joo Yeon Lee

Andreas Kemmler

Yong Sik Kwon

Alexander Boehm

Taehyung Lee

Henning Zahn

Jane Jung Lee

Kai Morich

Alexander Schroeder

Jeong Ae Han

Hyogi Jung

Zhi Qiao

Marcel Birn

Jihun Kang

Thomas Loetzer

Armin Risch

Incheol Kim

Christoph Glania

Various examples are directed to systems and methods for monitoring a plurality of container-implemented software application instances. A first ping agent executing in an orchestration container may launch a worker process in the orchestration container. The worker process may launch first and second worker threads in the orchestration container. The first worker thread may send a first ping message to a first application instance executing in a first application container outside the orchestration cluster. The second worker thread may send a second ping message to a second application instance executing in a second application container outside the orchestration cluster.

Monitoring container-implemented software applications

Systems and methods include execution of a first instance of a first service in an execution environment, transmission of a ping to an external port of the first instance, determination of a ping result corresponding to the transmitted ping, storage of metadata indicating a status of the first instance of the first service, determination of a health status metric of the first instance and providing the health status metric via an internal port of the execution environment, and determination of whether to generate an alert associated with the first instance based on the ping result, the status, and the health status metric.

Cluster availability monitoring and alerting

Some embodiments include a system, method, and non-transitory medium, with the system including an interface to at least one database product; a stateless ping operator to manage lifecycle events associated with the at least one database product; and a first product-specific ping agent to determine an availability of and generate metrics associated with a plurality of instances of a first specific database product of the at least one database product monitored by the first product-specific ping agent, the first product-specific ping agent receiving an assignment of the plurality of instances of the first specific database product to monitor from the ping operator.

Extensibility to monitor multiple products

Technologies are described for facilitating data workload capture, workload replay, and comparing the performance of a plurality of database systems. A plurality of requests for database operations are received from one or more database clients. The requests for database operations are executed. For the plurality of requests for database operations, execution context information is generated for a plurality of execution contexts. For the plurality of requests for database operations, a plurality of performance measures are generated. The execution context information and the performance measures are stored in a workload capture store, such as a file. The workload capture file is useable to replay the captured workload at a second database system using at least a portion of the execution context information and at least a portion of the performance measures.

Database workload capture and replay

Technologies are described for facilitating the processing of requests for database operations within a database environment that includes one or more processing units and a memory. A utilization level of one or more computing resources of a database system is periodically determined. When a request for a database operation is received from a database client, it is determined, such as based on the utilization level, whether the database system has sufficient resources to process the request. If the database system does not have sufficient resources to process the request, the request is enqueued in a request queue for deferred execution. If it is later determined that the database system has sufficient resources to execute the request, the request can be dequeued, executed, and execution results returned to the database client.

Dynamic admission control for database requests

Technologies are described for facilitating transaction processing within a database environment that includes one or more processing units and a memory. A request for a database operation, such as a query, is received from a client. Execution statistics associated with the request are retrieved. At least some of the execution statistics are compared with one or more threshold values. Based on results of the comparing, the request is carried out with a first execution component or delegated to a second execution component. The request is executed and execution results are sent to the client.

Selective dispatching of OLAP requests using execution statistics

Receiving a statement including requests for database operations in a secondary database system storing data replicated from a primary database system by replaying transaction output generated by the primary database system; responsive to receiving the statement, requesting an allocation of memory from the secondary database system to support the requested database operations; generating an aggregated statement memory consumption value based on the amount of memory consumed by all statements executing in the secondary database system that are not associated with replaying the transaction logs; determining that the requested allocation of memory in addition to the aggregated statement memory consumption value exceeds a total statement execution memory limit indicating a total amount of memory that may be allocated to all database operations associated with statement execution in a secondary database system, and denying the requested allocation of memory. Related apparatus, systems, techniques and articles are also described.

Database memory management in a high availability database system using limits

Systems, techniques, and articles are described herein for workload shifting in a database system. A computer system is configured to provide a database system and includes one or more processors, a primary database system implemented by the one or more processors, and a secondary database system implemented by the one or more processors. The secondary database system is configured as a hot-standby system for the primary database system and is capable of providing at least a minimum amount of essential functionality of the primary database system during a disruption. The primary database system is configured by programming instructions, executable on the computer system, to cause the one or more processors to determine from a query request from a client application directed to the primary database system that workload from a query may be shifted to the secondary database system and instruct the client application to execute the query.

Workload shifting in a database system using hint-based routing

A computer system is configured to provide a database system. The computer system comprises one or more processors, a primary database system implemented by the one or more processors, and a secondary database system implemented by the one or more processors. The secondary database system is configured as a hot-standby system for the primary database system. The secondary database system is capable of providing at least a minimum amount of essential functionality of the primary database system during a disruption to the primary database system. The secondary database system is configured by programming instructions, executable on the computer system, to cause the one or more processors to accept an authentication request from the client application to allow user access to the secondary database to execute the query and delegate an authentication check to the primary database system using connection credentials received from the client application. Related apparatus, systems, techniques and articles are also described.

Remote authentication in a database system

A process is provided for independently hashing and filtering a data set, such as during preprocessing. For the data set, one or more records, separately having one or more fields, may be identified. A record hash value set, containing one or more record hash values for the respective one or more records, may be generated. Generating a given record hash value may be accomplished as follows. For a given record, a hash value set may be generated, having one or more field hash values for the respective one or more fields of the given record. The record hash value for the given record may be generated based on the hash value set. A total hash value for the data set may be generated based on the record hash value set. The records of the data set may be filtered based on classification of the query that generated the records.

Order-independent multi-record hash generation and data filtering

A computer implemented method is provided for capturing and replaying a database workload by obtaining a workload capture file comprising execution context information generated in a database system and replayable to replicate the workload, generating a modified workload capture file by generating modified execution context information, replaying the modified workload capture file by generating at least one read statement based on the modified workload execution information and issuing at least one read statement to a primary database system having an associated secondary database system, determining that the at least one read statement may be routed to the secondary database system for execution, and routing the read statement to the secondary database system for execution. Related apparatus, systems, techniques and articles are also described.

Workload capture and replay for replicated database systems

Technologies are described for facilitating replay of requests for database operations. A plurality of requests for database operations are received. Each of the plurality of requests includes a type, an access unit identifier, and a chronological identifier. Execution dependencies are determined between the plurality of requests based on the type, access unit identifier, and chronological identifier of each of the plurality of requests. The execution dependencies are stored.

Parallelized replay of captured database workload

Growing community of inventors

Seoul, South Korea

Chul Won Lee