Pluggable Database Cloning in Read-Write Mode
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Current methods for cloning and moving pluggable databases (PDBs) require the source PDB to be in read-only mode, leading to significant downtime and increased costs due to the need for third-party tools and limitations in leveraging database optimizations, as well as difficulties in maintaining data consistency and minimizing disruption to users.
Innovation Solution
A method to clone or move a PDB while it remains in read-write mode, using native database mechanisms that maintain file and transactional consistency through initial and secondary recovery processes, allowing incremental refreshes and transparent connection forwarding to minimize downtime and costs.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Manufacturing precision
If the source PDB is placed in read-only mode for cloning, then data consistency is ensured, but operational availability deteriorates and downtime increases
Solution Approach 1:
The system performs preliminary actions by creating a consistent snapshot of the source PDB at a specific SCN before cloning begins, then uses this snapshot as the basis for the clone while the source continues to operate in read-write mode. This preliminary snapshotting action allows the clone to be created without requiring the source to remain in read-only mode throughout the entire cloning process.
Solution Approach 2:
The patent introduces an intermediary mechanism (the snapshot and SCN-based consistency model) that mediates between the source PDB and the clone. This intermediary allows data consistency to be maintained through the snapshot rather than through read-only mode constraints, enabling the source to remain operational while the clone is being created and subsequently refreshed.
2Adaptability or versatility
If third-party tools are used for PDB cloning, then cloning capability is achieved, but cost increases and database optimizations cannot be leveraged
Solution Approach 1:
The database system provides self-service cloning capabilities through native PDB clone commands that leverage the database's own internal mechanisms, redo logs, and recovery processes. This eliminates the need for external third-party tools, reducing costs and allowing the database to utilize its own optimized internal processes for cloning operations.
Solution Approach 2:
The patent implements a universal cloning mechanism that works across different PDB scenarios using the database's native capabilities. The same cloning infrastructure leverages existing database features like redo logs, recovery processes, and SCN management, making the cloning capability integrated and optimized within the database system rather than requiring external specialized tools.
3Manufacturing precision
If the entire PDB is cloned to ensure data consistency, then complete data replication is achieved, but time and resources are wasted cloning unchanged data
Solution Approach 1:
Instead of cloning the entire PDB, the system applies partial action by using incremental refreshes that only copy and apply changes (redo logs) since the last refresh or since the clone was created. This partial action approach maintains data consistency through incremental updates rather than requiring complete re-cloning, significantly reducing time and resources while ensuring the clone remains synchronized with the source.
Solution Approach 2:
The patent implements periodic incremental refreshes where the clone is updated at intervals by applying redo logs from the source PDB. This periodic action ensures the clone stays synchronized with the source over time without requiring continuous or complete re-cloning, optimizing both time efficiency and data consistency.
4Adaptability or versatility
If PDB cloning is performed over the network, then remote cloning is enabled, but transfer time increases significantly for large databases
Solution Approach 1:
The system performs preliminary action by utilizing the database's existing redo logs that are already generated during normal operations. Instead of capturing and transferring all data changes, the clone is initialized from a snapshot and then refreshed by applying these pre-existing redo logs, which significantly reduces the amount of data that needs to be transferred over the network compared to traditional cloning methods.
Solution Approach 2:
The patent extracts only the necessary change information (redo logs) from the source PDB for transfer to the clone, rather than transferring the entire database or all data files. This extraction approach minimizes network transfer time by sending only the incremental changes needed to keep the clone synchronized, while still enabling remote cloning capability.
Data Source
AI summary
Embodiments create a clone of a PDB while the PDB accepts write operations. While the PDB remains in read-write mode, the DBMS copies the data of the PDB and sends the data to a destination location. The DBMS performs data recovery on the PDB clone based on redo entries that record changes made to the source PDB while the DBMS copied the source PDB files. This data recovery makes all changes, to the PDB clone, that occurred to the source PDB during the copy operation. The redo information, on which the data recovery is based, is foreign to the PDB clone since the redo entries were recorded for a different PDB. In order to apply foreign redo information to perform recovery on the PDB clone, a DBMS managing the PDB clone maintains mapping information that maps PDB source reference information to corresponding information for the PDB clone.