Oracle International Corporation

Other

Lik Wong

Nimar Singh Arora

Dustin R Garvey

James William Stamos

Uri Shaft

Sampanna Shahaji Salunke

Anand Lakshminath

Mark Dilman

Leonid Novak

Alan Robert Downing

Wei-Ming Hu

Kenny C Gross

Amit Ganesh

Wei Wang

Neerja Bhatt

Alan J Demers

Sanjay Kaluskar

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

Thuvan Hoang

Edwina Lu

Edwina Ming-Yue Lu

Byron Wang

Lei Gao

Jun Yuan

Jingwei Wu

Girish Kumar Balachandran

Haobo Xu

Ramkumar Venkatesan

Shravan Kumar Shivanagari

Taylor Scott Gautier

Patricia H McElroy

Vasanth Rajamani

Sundeep Abraham

Saurabh Verma

Hung Viet Tran

John R Ciminski

Ilesh Garish

Cristina Schmidt

Sean Lehouillier

Geeta Arora

Mahesh Subramaniam

Curtis Elsbernd

Qinqin Wang

Parthasarathy Elangadu Raghunathan

Francisco Sanchez

Lakshminaray Chidambaran

Neeraj Shodhan

Karen Theisen

Thuyan Hoang

Ashutosh Gupta

Anthony Giardullo

Tianshu Li

Neeraj Shadhan

Rajesh Easwaramoorthy

Yongqiang Zhang

Xuemei Gao

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