Abstract: Managing databases implemented in a cloud computing environment. A method includes detecting that a database implemented in the cloud computing environment is in a state of non-use. The method further includes as a result of detecting that a database implemented in the cloud computing environment is in a state of non-use, instantiating a workload in the cloud computing environment to deactivate the database. The workload is configured to store metadata for the database and database data remotely in cloud storage such that the database can be reactivated at a later time.

Abstract: Embodiments of the invention dynamically vary the number of replicas based on certain conditions to protect users from data loss. The size of the database is one condition that can be used to determine the number of replicas required. A database system may create three replicas. When the database size exceeds a first threshold, a fourth replica may be created. The fourth replica is maintained as long as the database size is above a second threshold that is smaller than the first threshold. However, when the database shrinks below the second threshold, then the fourth replica is deleted. Using two different thresholds in this manner prevents the system from frequently cycling between three and four replicas.

Abstract: Embodiments of the invention dynamically vary the number of replicas based on certain conditions to protect users from data loss. The size of the database is one condition that can be used to determine the number of replicas required. A database system may create three replicas. When the database size exceeds a first threshold, a fourth replica may be created. The fourth replica is maintained as long as the database size is above a second threshold that is smaller than the first threshold. However, when the database shrinks below the second threshold, then the fourth replica is deleted. Using two different thresholds in this manner prevents the system from frequently cycling between three and four replicas.

Abstract: Embodiments of the invention dynamically vary the number of replicas based on certain conditions to protect users from data loss. The size of the database is one condition that can be used to determine the number of replicas required. A database system may create three replicas. When the database size exceeds a first threshold, a fourth replica may be created. The fourth replica is maintained as long as the database size is above a second threshold that is smaller than the first threshold. However, when the database shrinks below the second threshold, then the fourth replica is deleted. Using two different thresholds in this manner prevents the system from frequently cycling between three and four replicas.

Abstract: Architecture that addresses an end-to-end solution for logical transactional replication from a shared-nothing clustered database management system, which uses adaptive cloning for high availability. This can be time based using a global logical timestamp. The disclosed architecture, used for refreshing stale clones, does not preserve user transaction boundaries, which is a more complex situation than where the boundaries are preserved. In such a scenario it is probable that for a given data segment no clone of the segment may contain the complete user transaction history, and hence, the history has to be pieced together from the logs of multiple different clones. This is accomplished such that log harvesting is coordinated with the clone state transitions to ensure the correctness of logical replication.

Abstract: A method for distributing one or more conflicting data changes. The method includes extracting data changes from the source site log, and applying the data changes to the destination site. The method then includes identifying one or more constraints for each data change and generating a hash value for each identified constraint. The method then dispatches the data changes into a plurality of streams based on the hash values. The hash values are used to identify conflicting data changes and determine how the data changes should be sent through the plurality of streams such that data changes are applied in parallel in the plurality of streams without violating any causal consistency constraints. The method then includes committing data changes in the plurality of streams to the destination site in a single transaction, creating a consistent transactional view.

Abstract: Embodiments of the invention dynamically vary the number of replicas based on certain conditions to protect users from data loss. The size of the database is one condition that can be used to determine the number of replicas required. A database system may create three replicas. When the database size exceeds a first threshold, a fourth replica may be created. The fourth replica is maintained as long as the database size is above a second threshold that is smaller than the first threshold. However, when the database shrinks below the second threshold, then the fourth replica is deleted. Using two different thresholds in this manner prevents the system from frequently cycling between three and four replicas.

Abstract: Architecture that addresses an end-to-end solution for logical transactional replication from a shared-nothing clustered database management system, which uses adaptive cloning for high availability. This can be time based using a global logical timestamp. The disclosed architecture, used for refreshing stale clones, does not preserve user transaction boundaries, which is a more complex situation than where the boundaries are preserved. In such a scenario it is probable that for a given data segment no clone of the segment may contain the complete user transaction history, and hence, the history has to be pieced together from the logs of multiple different clones. This is accomplished such that log harvesting is coordinated with the clone state transitions to ensure the correctness of logical replication.

Abstract: Aspects of the subject matter described herein relate to multi-log based replication. In aspects, database fragments are associated with different logs. Each change to a duplicated database record may be recorded in multiple logs. A history data structure is used to determine when duplication schemas are valid. A duplication schema indicates what database fragments duplicate one or more database records. For a particular time range, the duplication schema history is used to determine whether currently available logs include all changes. If multiple logs include the same change, one log may be selected to provide the change. Non-duplicative changes may be placed into a single data stream usable to update a remote database.

Abstract: Aspects of the subject matter described herein relate to data change ordering in multi-log based replication. In aspects, local seeds are maintained for subtransactions involved in a transaction, where each subtransaction may occur on a different node that hosts one or more database fragments involved in the transaction. When a subtransaction communicates with another subtransaction in a transaction, the subtransaction sends its local seed to the other subtransaction. The receiving subtransaction compares its local seed with the received seed and updates its local seed if the received seed is logically after its local seed. A subtransaction uses a local seed to generate sequence identifiers for changes made by the subtransaction. These identifiers allow data changes of a transaction that are made on multiple nodes to be partially ordered relative to other changes made during the transaction.

Abstract: Architecture that addresses an end-to-end solution for logical transactional replication from a shared-nothing clustered database management system, which uses adaptive cloning for high availability. This can be time based using a global logical timestamp. The disclosed architecture, used for refreshing stale clones, does not preserve user transaction boundaries, which is a more complex situation than where the boundaries are preserved. In such a scenario it is probable that for a given data segment no clone of the segment may contain the complete user transaction history, and hence, the history has to be pieced together from the logs of multiple different clones. This is accomplished such that log harvesting is coordinated with the clone state transitions to ensure the correctness of logical replication.

Abstract: Systems and methods that supply changes on-the-fly and without breaking execution of codes for schema changes in a peer-to-peer environment. The modification component supplies changes to peers or nodes in a topology by initially identifying dependencies (e.g., multiple level) that can be affected by the schema change, followed by performing the schema change to the codes or stored procedures. Accordingly, dependencies in an entire system can be refreshed, wherein multiple levels of dependencies can exist.

Abstract: A method for distributing one or more conflicting data changes. The method includes extracting data changes from the source site log, and applying the data changes to the destination site. The method then includes identifying one or more constraints for each data change and generating a hash value for each identified constraint. The method then dispatches the data changes into a plurality of streams based on the hash values. The hash values are used to identify conflicting data changes and determine how the data changes should be sent through the plurality of streams such that data changes are applied in parallel in the plurality of streams without violating any causal consistency constraints. The method then includes committing data changes in the plurality of streams to the destination site in a single transaction, creating a consistent transactional view.

Abstract: Aspects of the subject matter described herein relate to multi-log based replication. In aspects, database fragments are associated with different logs. Each change to a duplicated database record may be recorded in multiple logs. A history data structure is used to determine when duplication schemas are valid. A duplication schema indicates what database fragments duplicate one or more database records. For a particular time range, the duplication schema history is used to determine whether currently available logs include all changes. If multiple logs include the same change, one log may be selected to provide the change. Non-duplicative changes may be placed into a single data stream usable to update a remote database.

Abstract: Aspects of the subject matter described herein relate to data change ordering in multi-log based replication. In aspects, local seeds are maintained for subtransactions involved in a transaction, where each subtransaction may occur on a different node that hosts one or more database fragments involved in the transaction. When a subtransaction communicates with another subtransaction in a transaction, the subtransaction sends its local seed to the other subtransaction. The receiving subtransaction compares its local seed with the received seed and updates its local seed if the received seed is logically after its local seed. A subtransaction uses a local seed to generate sequence identifiers for changes made by the subtransaction. These identifiers allow data changes of a transaction that are made on multiple nodes to be partially ordered relative to other changes made during the transaction.

Abstract: Systems and methods that enable conflict detection in a peer-to-peer replication by embedding origination information in data records. A tracing component can track embedded information in form of peer ID and transaction ID, wherein conflicts can be detected by comparing a pre-version (prior to current version) of data on the source node—with—a current version of the data on the destination node.

Abstract: A transactional replication system wherein each replicated command applies to a single row as identified by the primary key, replicated commands are dispatched among multiple connections by hashing of primary key from a single command queue to ensure that changes to the same data row are always dispatched to the same connection to maintain the order of commands as originally occurred on publisher. All connections commit their transactions at the same time in a coordinated fashion without a two phase commit. Retry logic based on a logical sequence number is used to reapply commands from any connection that fails to commit.

Abstract: A well-known transactions feature in data replication that takes the “last seen” transaction watermark, stores the watermark for each source in a topology, and tags each transaction with information associated with its origin. The tagged data is called Originator Information, and contains, but is not limited to, information on the originating server, originating database, and the originating transaction. This technology provides users with a method to scale out (keep more than two nodes in synchronism with updates at all nodes), increase availability of data during limited network failures (multiple replication pathways), and improve recovery strategies (redeliver transactions upon restore).

Abstract: Systems and methods that supply changes on-the-fly and without breaking execution of codes for schema changes in a peer-to-peer environment. The modification component supplies changes to peers or nodes in a topology by initially identifying dependencies (e.g., multiple level) of that can be affected by the schema change, followed by performing the schema change to the codes or stored procedures. Accordingly, dependencies in entire system can be refreshed, wherein multiple levels of dependencies can exist.

Abstract: The present invention relates to a medium-pressure hydrocracking process which uses a fresh hydrogen resource and a hydrosaturation catalyst with reduced metals of group VIB and/or group VIII as the active ingredients to selectively and deeply hydrosaturate jet fuel and/or diesel cuts derived in the medium-pressure hydrocracking process.