Oracle International Corporation

Other

Lik Wong

Nimar Singh Arora

Dustin R Garvey

James William Stamos

Uri Shaft

Sampanna Shahaji Salunke

Thuvan Hoang

Leonid Novak

Anand Lakshminath

Mark Dilman

Alan Robert Downing

Wei-Ming Hu

Kenny C Gross

Amit Ganesh

Wei Wang

Neerja Bhatt

Sanjay Kaluskar

Alan J Demers

Benny Souder

Maria Elisabeth Kaval

Aleksey M Urmanov

Douglas N Surber

Jean De Lavarene

Wei Ming Hu

Saurabh Kumar Verma

Subramanian Muralidhar

Ravi Murthy

Zhen Hua Liu

Muralidhar Krishnaprasad

Sivasankaran Chandrasekar

Kalyanaraman Vaidyanathan

Lakshminarayanan Luxi Chidambaran

Dheeraj Pandey

Eric S Chan

James W Warner

Eric L Sutton

Joydip Kundu

Edwina Lu

Lei Gao

Byron Wang

Jingwei Wu

Ramkumar Venkatesan

Geeta Arora

Saurabh Verma

Edwina Ming-Yue Lu

Hung Viet Tran

Jun Yuan

Haobo Xu

Girish Kumar Balachandran

John R Ciminski

Shravan Kumar Shivanagari

Ilesh Garish

Vasanth Rajamani

Cristina Schmidt

Sean Lehouillier

Taylor Scott Gautier

Patricia H McElroy

Sundeep Abraham

Mahesh Subramaniam

Qinqin Wang

Curtis Elsbernd

Parthasarathy Elangadu Raghunathan

Francisco Sanchez

Lakshminaray Chidambaran

Neeraj Shodhan

Yongqiang Zhang

Neeraj Shadhan

Anthony Giardullo

Thuyan Hoang

Tianshu Li

Xuemei Gao

Rajesh Easwaramoorthy

Ashutosh Gupta

Karen Theisen

Maria Kaval

A node within a group of participant nodes begins an election by sending a vote request to the other nodes in the group. The vote request sets an input term argument to a future term value without incrementing the actual current term value. The current term value at each participant node is only incremented in response to a successful leadership change. At startup time, a candidate node issues a vote request with a non-disruptive election type. An established leader automatically rejects a non-disruptive vote request. A heartbeat loss vote request is rejected by each receiving node if its own heartbeat timeout does not exceed a predetermined limit. A mandatory vote request informs the leader node that it should stop requesting new workload. This is used in manual leadership transition to make sure that the old leader does not accept new transactions during the leadership transition.

Keeping stable leadership in raft-based protocol with fast automatic failover

Replication is improved in a globally distributed database, such as a replicated sharded database, which uses raft-based asynchronous database replication. Improvements include Raft log persistence, coordination of followers' processing speed, transaction outcome determination, and column name compression, and improved failover time through heartbeat consolidation and keeping apply processes of followers running across failovers.

Performance optimization in raft-based asynchronous database transaction replication

A consensus protocol-based replication approach is provided. Chunks are grouped into replication units (RUs) to optimize replication efficiency. Chunks may be assigned to RUs based on load and replication throughput. Splitting and merging RUs do not interrupt concurrent user workload or require routing changes. Transactions spanning chunks within an RU do not require distributed transaction processing. Each replication unit has a replication factor (RF), which refers to the number of copies/replicas of the replication unit, and an associated distribution factor (DF), which refers to the number of servers taking over the workload from a failed leader server. RUs may be placed in rings of servers, where the number of servers in a ring is equal to the replication factor, and quiescing the workload can be restricted to a ring of servers instead of the entire database.

Configuration and management of replication units for asynchronous database transaction replication

A lead-sync log record is used to synchronize the replication logs of follower shards to the leader shard. In response to a failure to determine that there is a consensus for a database transaction commit operation after a shard server becomes a new leader, the new leader shard performs a sync operation using the lead-sync log record to synchronize replication logs of the follower shards to the replication log of the new leader. A shard server identifies a first transaction having a first log record but not a post-commit log record in the replication log, defines a recovery window in the replication log starting at the first log record of the identified first transaction and ending at the lead-sync log record, identifies a set of transactions to be recovered, and performs a recovery action on the set of transactions to be recovered.

Recovery from loss of leader during asynchronous database transaction replication

A consensus protocol-based replication approach is provided. For each change operation performed by a leader server on a copy of the database, the leader server creates a replication log record and returns a result to the client. The leader does not wait for consensus for the change operation from the followers. For a commit, the leader creates a commit log record and waits for consensus. Thus, the leader executes database transactions asynchronously, performs replication of change operations asynchronously, and performs replication of transaction commits synchronously.

Consensus protocol for asynchronous database transaction replication with fast, automatic failover, zero data loss, strong consistency, full SQL support and horizontal scalability

Techniques are described for automatically detecting and accommodating state changes in a computer-generated forecast. In one or more embodiments, a representation of a time-series signal is generated within volatile and/or non-volatile storage of a computing device. The representation may be generated in such a way as to approximate the behavior of the time-series signal across one or more seasonal periods. Once generated, a set of one or more state changes within the representation of the time-series signal is identified. Based at least in part on at least one state change in the set of one or more state changes, a subset of values from the sequence of values is selected to train a model. An analytical output is then generated, within volatile and/or non-volatile storage of the computing device, using the trained model.

Systems and methods for detecting and accommodating state changes in modelling

Techniques are described for classifying seasonal patterns in a time series. In an embodiment, a set of time series data is decomposed to generate a noise signal and a dense signal, where the noise signal includes a plurality of sparse features from the set of time series data and the dense signal includes a plurality of dense features from the set of time series data. A set of one or more sparse features from the noise signal is selected for retention. After selecting the sparse features, a modified set of time series data is generated by combining the set of one or more sparse features with a set of one or more dense features from the plurality of dense features. At least one seasonal pattern is identified from the modified set of time series data. A summary for the seasonal pattern may then be generated and stored.

Unsupervised method for classifying seasonal patterns

Techniques are described for generating seasonal forecasts. According to an embodiment, a set of time-series data is associated with one or more classes, which may include a first class that represent a dense pattern that repeats over multiple instances of a season in the set of time-series data and a second class that represent another pattern that repeats over multiple instances of the season in the set of time-series data. A particular class of data is associated with at least two sub-classes of data, where a first sub-class represents high data points from the first class, and a second sub-class represents another set of data points from the first class. A trend rate is determined for a particular sub-class. Based at least in part on the trend rate, a forecast is generated.

Seasonal aware method for forecasting and capacity planning

Techniques are provided for processing a database command in a sharded database. The processing of the database command may include generating or otherwise accessing a shard key expression, and evaluating the shard key expression to identify one or more target shards that contain data used to execute the database command.

Automatic derivation of shard key values and transparent multi-shard transaction and query support

Techniques are described for characterizing and summarizing seasonal patterns detected within a time series. According to an embodiment, a set of time series data is analyzed to identify a plurality of instances of a season, where each instance corresponds to a respective sub-period within the season. A first set of instances from the plurality of instances are associated with a particular class of seasonal pattern. After classifying the first set of instances, a second set of instances may remain unclassified or otherwise may not be associated with the particular class of seasonal pattern. Based on the first and second set of instances, a summary may be generated that identifies one or more stretches of time that are associated with the particular class of seasonal pattern. The one or more stretches of time may span at least one sub-period corresponding to at least one instance in the second set of instances.

System for detecting and characterizing seasons

Techniques are described for generating period profiles. According to an embodiment, a set of time series data is received, where the set of time series data includes data spanning a plurality of time windows having a seasonal period. Based at least in part on the set of time-series data, a first set of sub-periods of the seasonal period is associated with a particular class of seasonal pattern. A profile for a seasonal period that identifies which sub-periods of the seasonal period are associated with the particular class of seasonal pattern is generated and stored, in volatile or non-volatile storage. Based on the profile, a visualization is generated for at least one sub-period of the first set of sub-periods of the seasonal period that indicates that the at least one sub-period is part of the particular class of seasonal pattern.

Method for creating period profile for time-series data with recurrent patterns

Techniques are described for modeling variations in correlation to facilitate analytic operations. In one or more embodiments, at least one computing device receives first metric data that tracks a first metric for a first target resource and second metric data that tracks a second metric for a second target resource. In response to receiving the first metric data and the second metric data, the at least one computing device generates a time-series of correlation values that tracks correlation between the first metric and the second metric over time. Based at least in part on the time-series of correlation data, an expected correlation is determined and compared to an observed correlation. If the observed correlation falls outside of a threshold range or otherwise does not satisfy the expected correlation, then an alert and/or other output may be generated.

Correlation-based analytic for time-series data

Growing community of inventors

Union City, CA, United States of America

Lik Wong