Data flashback method, device and equipment of automatic stereoscopic library system and storage medium

Abstract

This application discloses a data flashback method, apparatus, equipment, and storage medium for an automated storage and retrieval system (AS / RS), relating to the field of warehousing technology. This method adapts to the continuous operation requirements of AS / RS, constructing an automated data anomaly identification and recovery process. It overcomes the shortcomings of traditional recovery processes, such as cumbersome procedures, significant downtime impact, and poor adaptability. It adapts to various anomaly scenarios, reduces the impact on system operation, improves data security and business stability, reduces manual intervention, and optimizes recovery accuracy and efficiency. Step S1 provides a complete and effective basic data source for the entire process; Step S2 completes multi-source data standardization processing, providing adaptive input for anomaly detection; Step S3 accurately locates anomaly events, providing a basis for solution formulation; Step S4 matches an adapted flashback strategy to ensure the rationality of the solution; Step S5 executes the corresponding level of flashback operation to complete the target data recovery; Step S6 completes full-dimensional verification of the recovered data, ensuring data consistency and availability.

Description

Technical Field

[0001] This application relates to the field of warehousing technology, and in particular to a data flashback method, apparatus, equipment and storage medium for an automated storage and retrieval system. Background Technology

[0002] Automated Storage and Retrieval Systems (AS / RS) are intelligent warehousing systems that use high-rise racking as storage carriers, achieve end-to-end control through computer systems, and rely on stacker cranes, conveyor systems, and intelligent operating equipment to automate the storage and retrieval of goods. They are core infrastructure in modern intelligent manufacturing and smart logistics systems, and are widely used in industries such as tobacco, pharmaceuticals, automotive, and e-commerce retail. The stable operation of this system's entire process, including warehouse scheduling, inventory management, equipment control, and business traceability, depends entirely on the accuracy, completeness, and continuity of data in the core business database. Any errors, abnormal changes, damage, or loss of database data will directly lead to warehousing operations interruption, causing serious business losses and operational risks.

[0003] The conventional methods for data recovery in automated storage and retrieval systems mainly rely on traditional database backup and recovery techniques. The primary approach is an offline recovery mode that combines full backups with incremental backups. Some solutions use basic database log rollback operations to correct data.

[0004] Currently, traditional backup and recovery methods rely on pre-generated backup files, and the recovery process is cumbersome and time-consuming, causing long-term system downtime and failing to meet the high availability requirements of continuous operation in automated storage and retrieval systems. Summary of the Invention

[0005] The main objective of this application is to provide a data flashback method, apparatus, device, and storage medium for an automated storage and retrieval system, in order to solve the problem that the traditional backup and recovery mode in the prior art relies on pre-generated backup files, and the recovery operation process is cumbersome and time-consuming, which will cause the system to be shut down for a long time and cannot meet the high availability requirements of continuous operation of automated storage and retrieval systems.

[0006] To achieve the above objectives, this application provides the following technical solution: A data flashback method for an automated storage and retrieval system, the data flashback method comprising: Step S1: Collect the full operation logs, business operation time sequence data, and data change trajectory sequence of the automated storage and retrieval system database; Step S2: Perform time-series alignment and standardized encoding on the full operation log, the business operation time-series data, and the data change trajectory sequence to generate a multivariate time-series standardized dataset; Step S3: Input the multivariate time-series standardized dataset into the PatchTST time-series anomaly detection algorithm to locate abnormal data change events and obtain the result set of abnormal event time interval location. Step S4: Input the abnormal event time interval location result set into the MOEA / D multi-objective optimization algorithm, and obtain the target flashback execution plan by matching the optimal recovery level and execution rules of Oracle flashback; Step S5: Perform the corresponding level of flashback operation according to the target flashback execution plan to generate the full dataset of the business database after flashback; Step S6: Perform data verification on the full dataset of the business database after the flashback. If the verification is successful, the full dataset of the restored database is obtained.

[0007] Beneficial effects of steps S1 to S6: This method is adapted to the continuous operation requirements of automated storage and retrieval systems (AS / RS), constructing an automated data anomaly identification and recovery process. It overcomes the shortcomings of traditional data recovery methods, such as cumbersome processes, significant downtime impact, and insufficient adaptability. It can adapt to data anomaly scenarios of varying degrees, reduce the impact of data recovery on normal system operation, improve the data security and operational stability of AS / RS, reduce manual intervention in the data recovery process, optimize the accuracy and efficiency of data recovery, and provide support for the stable operation of the system's core business.

[0008] Step S1 provides a unified basic data source for subsequent full-process data processing, ensuring the integrity and validity of the input data; Step S2 completes the standardization processing of multi-source data, eliminating differences in different data dimensions and providing suitable input data for subsequent anomaly detection; Step S3 completes the accurate location of data anomaly events, providing accurate basis for the formulation of recovery plans; Step S4 matches suitable flashback recovery strategies, ensuring the rationality and scenario adaptability of the recovery plan; Step S5 completes the flashback operation at the corresponding level, realizing the recovery execution of the target data; Step S6 completes the full-dimensional verification of the recovered data, ensuring the consistency and availability of the recovered data.

[0009] As a further improvement to this application, step S1 involves collecting the full operation logs, business operation time-series data, and data change trajectory sequences of the automated storage and retrieval system database, including: Step S1.1: Connect the standardized communication interface between the core database of the automated storage and retrieval system and the business execution system to establish a real-time channel for reading all data. Step S1.2: Continuously capture all running logs generated during database operation through the real-time full data reading channel; Step S1.3: Synchronously collect business operation time sequence data that matches the time axis of the full operation log through the full data real-time reading channel; Step S1.4: Capture the database data change trajectory sequence corresponding to the full operation log and the business operation time sequence data through the full data real-time reading channel; Step S1.5: Remove invalid null values ​​and duplicate data fragments from the full operation log, the business operation time sequence data, and the data change trajectory sequence; Step S1.6: Output the full running log, business operation time sequence data, and data change trajectory sequence that have been verified.

[0010] Beneficial effects of steps S1.1 to S1.6: This series of steps establishes a stable and compliant data acquisition link for the data flashback process of the automated storage and retrieval system, enabling multi-dimensional operation of the core database and automated acquisition and basic verification of business data. It ensures the integrity and consistency of the data source, avoids problems such as misalignment of time sequences of multi-source data and interference from invalid data, provides compliant and usable basic data support for the entire data flashback process, and adapts to the real-time data acquisition needs during the continuous operation of the system.

[0011] The process includes the following steps: Step S1.1: Establishing a standardized data transmission channel between the system and the database to ensure the compliance and stability of the data collection process; Step S1.2: Continuously capturing database operation logs to provide basic support for end-to-end data traceability; Step S1.3: Synchronously collecting business operation data to ensure the temporal matching of operation data and business data; Step S1.4: Obtaining database data change trajectory information to provide original evidence for data anomaly tracing; Step S1.5: Performing basic cleaning of the raw data to remove invalid data fragments and improve the usability of the basic data; and Step S1.6: Outputting the verified basic data to complete the closed-loop management of the data collection process.

[0012] As a further improvement to this application, step S2 involves performing time-series alignment and standardized encoding on the full operation log, the business operation time-series data, and the data change trajectory sequence to generate a multivariate time-series standardized dataset, including: Step S2.1: Obtain the full operation log, the business operation time sequence data, and the data change trajectory sequence, and extract the set of native timestamp fields corresponding to each data dimension; Step S2.2: Perform time-series alignment on all data dimensions of the original timestamp field set based on a unified time granularity to obtain the time-series aligned full running log, business operation time-series data, and data change trajectory sequence. Step S2.3: Perform a mapping transformation from unstructured data to structured numerical data on the time-aligned full operation log, business operation time-series data, and data change trajectory sequence to obtain the structured encoded full operation log, business operation time-series data, and data change trajectory sequence. Step S2.4: Perform global numerical standardization on the structured encoded full operation log, business operation time series data, and data change trajectory sequence to obtain full operation log, business operation time series data, and data change trajectory sequence with unified dimensions; Step S2.5: The full-scale operation logs, business operation time-series data, and data change trajectory sequences with unified dimensions are spliced ​​and integrated along the same time axis to obtain a multi-dimensional time-series standardized dataset.

[0013] Beneficial effects of steps S2.1 to S2.5: This series of steps completes the time-series regularization and standardization of multi-source heterogeneous data after collection, solving the problems of misaligned time sequences, inconsistent formats, and large dimensional differences in the original data. It enables the same baseline management of multi-dimensional business and operational data, provides well-suited input data for subsequent anomaly detection algorithms, reduces the error risk of subsequent data processing, ensures the continuity and consistency of data processing throughout the entire process, and adapts to the multi-source data processing needs of automated storage and retrieval systems.

[0014] The process includes the following steps: Step S2.1 extracts the native timestamp fields of each data dimension to provide a unified benchmark for the entire time-series processing; Step S2.2 performs time-series alignment of multi-source data to eliminate time-series deviations between different data dimensions and ensure the temporal correlation between data; Step S2.3 converts unstructured data into structured numerical data, unifies the format of multi-source data, and improves data processability; Step S2.4 performs global numerical standardization to eliminate the differences in units of measurement between different data dimensions and reduce interference factors in subsequent algorithm processing; and Step S2.5 performs coaxial integration of multi-dimensional data and outputs a standardized dataset that meets the requirements of subsequent processing, thus achieving a closed loop in the data preprocessing process.

[0015] As a further improvement to this application, step S3 involves inputting the multivariate time-series standardized dataset into the PatchTST time-series anomaly detection algorithm to locate abnormal data change events, thereby obtaining a set of abnormal event time interval localization results, including: Step S3.1: Obtain the multivariate time-series standardized dataset and extract the corresponding time axis index sequence and multidimensional feature sequence; Step S3.2: Input the time axis index sequence and the multi-dimensional feature sequence into the PatchTST time series anomaly detection algorithm, and generate a block-embedded feature sequence with position information through sequence segmentation and position encoding operations; Step S3.3: Input the block-embedded feature sequence into the Transformer encoder layer of the PatchTST temporal anomaly detection algorithm to perform global temporal dependency modeling and calculation, and obtain the global temporal feature representation sequence; Step S3.4: Perform reverse reconstruction calculation of the time-series dimension on the global time-series feature representation sequence to obtain a reconstructed time-series dataset that matches the dimension of the multivariate time-series standardized dataset; Step S3.5: Perform point-by-point residual calculation on the reconstructed time series dataset and the multivariate time series normalized dataset to generate a time series residual sequence; Step S3.6: Perform adaptive anomaly threshold determination and continuous time interval aggregation on the time-series residual sequence to locate the boundary of abnormal data change events, and obtain the abnormal event time interval location result set.

[0016] Beneficial effects of steps S3.1 to S3.6: This series of steps relies on time-series anomaly detection algorithms to accurately identify and locate anomalies in standardized datasets, solving the problems of insufficient accuracy and ambiguous boundaries in existing technologies for locating data anomalies. It mines deep anomaly features in time-series data, providing accurate time intervals for subsequent recovery plan formulation. It adapts to the automated identification needs of data anomalies during the continuous operation of automated storage and retrieval systems, reducing the cost and error of manual investigation and improving the efficiency and accuracy of anomaly event location.

[0017] The process involves the following steps: Step S3.1 extracts the timeline index and multi-dimensional feature sequences corresponding to the dataset, providing a basic temporal and feature reference for subsequent algorithm processing; Step S3.2 completes sequence segmentation and position encoding, preserving the positional correlation information of the time-series data and enhancing the identifiability of the time-series features; Step S3.3 completes global temporal dependency modeling, mining deep correlation features between data, and improving the sensitivity of anomaly identification; Step S3.4 completes reverse reconstruction calculation of the time-series dimension, generating a reference dataset that matches the original data dimension; Step S3.5 completes point-by-point residual calculation, quantifying the deviation between the original data and the reconstructed data, providing a quantitative basis for anomaly judgment; and Step S3.6 completes anomaly threshold judgment and interval aggregation, realizing the boundary location of abnormal events and outputting clear time interval results for abnormal events.

[0018] As a further improvement to this application, step S4 involves inputting the abnormal event time interval location result set into the MOEA / D multi-objective optimization algorithm. By matching the optimal recovery level and execution rules of Oracle flashback, a target flashback execution plan is obtained, including: Step S4.1: Obtain the set of abnormal event time interval location results and construct the decision variable space, constraint set, and optimization objective function set adapted to the MOEA / D multi-objective optimization algorithm; Step S4.2: Input the decision variable space, the constraint set, and the optimization objective function set into the MOEA / D multi-objective optimization algorithm, and generate the initialized MOEA / D multi-objective optimization algorithm population and weight vector set through algorithm population initialization and uniform weight vector distribution operations; Step S4.3: Perform neighborhood update and crossover mutation operations on the MOEA / D multi-objective optimization algorithm population and the weight vector set to obtain a new generation optimization population individual set; Step S4.4: Perform fitness calculation for Chebyshev aggregation function adaptation on the set of individuals in the new generation of optimized population, and screen and sort non-dominated solutions to obtain the Pareto optimal solution set; Step S4.5: Match and map the Pareto optimal solution set with the Oracle flashback recovery level and execution rule base to generate a set of candidate flashback execution schemes; Step S4.6: Perform global optimal solution screening on the candidate flashback execution scheme set to obtain the target flashback execution scheme.

[0019] Beneficial effects of steps S4.1 to S4.6: This series of steps relies on multi-objective optimization algorithms to automate the generation and optimization of flashback recovery solutions. It addresses the issues of insufficient adaptability of recovery strategies and strong subjectivity in manual solution formulation in existing technologies. It balances multiple dimensions of needs such as recovery efficiency, recovery accuracy, and impact on system operation, matches appropriate flashback execution strategies for different abnormal scenarios, reduces manual intervention in the solution formulation process, provides clear and reasonable execution basis for subsequent flashback operations, and adapts to the diverse data anomaly recovery needs of automated three-dimensional warehouse systems.

[0020] The process involves the following steps: Step S4.1 establishes a computational framework adapted to the optimization algorithm, clarifying the decision boundaries and objectives for subsequent optimization calculations; Step S4.2 initializes the algorithm population and assigns weights to ensure the coverage and computational stability of the optimization process; Step S4.3 iteratively updates the population, expanding the search range of the solution space and improving the efficiency of obtaining high-quality solutions; Step S4.4 calculates fitness and filters non-dominated solutions to obtain the optimal solution set that meets multi-dimensional requirements; Step S4.5 matches and maps the optimal solution set with the flashback rule base, generating multiple sets of compliant candidate recovery schemes; and Step S4.6 filters the globally optimal scheme and outputs a flashback execution scheme adapted to the current abnormal scenario.

[0021] As a further improvement to this application, step S5 involves executing the corresponding level of flashback operation according to the target flashback execution plan to generate a full dataset of the business database after the flashback, including: Step S5.1: Obtain the target flashback execution plan and extract the flashback recovery level, target time node, scope of operation object, and execution timing rules within the plan; Step S5.2: Pre-allocate and lock resources for the flashback recovery level, the target time node, the scope of the operation object, the execution timing rules, and the execution interface of Oracle database flashback technology to obtain the flashback execution environment configuration parameters that have been adapted. Step S5.3: Decompose the execution timing and map the instructions of the flashback execution environment configuration parameters to generate a standardized flashback operation instruction sequence; Step S5.4: The standardized flashback operation instruction sequence is sent to the database execution kernel to perform the corresponding level of flashback operation, generating a database change log and a temporary recovery dataset; Step S5.5: Perform full data integration and format synchronization on the database change log and temporary recovery dataset to generate a full dataset of the business database after flashback.

[0022] Beneficial effects of steps S5.1 to S5.5: This series of steps completes the implementation of the flashback execution solution, establishes a standardized automated flashback operation execution chain, solves the problems of cumbersome traditional data recovery operation processes, excessive manual intervention, and insufficient execution stability, ensures the compatibility of flashback operation with the database operating environment, reduces the impact of recovery operation on normal system operation, achieves accurate recovery execution of target data, provides a standardized and unified dataset for subsequent data verification, and adapts to the continuous operation requirements of automated storage and retrieval systems.

[0023] The process includes the following steps: Step S5.1 extracts the core execution parameters from the execution plan to provide a clear execution benchmark for subsequent full-process operations; Step S5.2 completes the adaptation verification and resource pre-allocation of the execution environment to ensure the compliant and stable execution of the flashback operation; Step S5.3 completes the decomposition of the execution sequence and instruction mapping to generate a standardized execution instruction sequence; Step S5.4 completes the kernel execution of the flashback operation to realize the recovery processing of the target data; and Step S5.5 completes the full integration and format synchronization of the recovered data to output a standardized full dataset of the business database after the flashback.

[0024] As a further improvement to this application, step S6 involves verifying the full dataset of the business database after the flashback. Upon successful verification, the full dataset of the recovered database is obtained, including: Step S6.1: Obtain the full dataset of the business database after the flashback and extract the business table structure metadata, data row record set, and time-series change trajectory information corresponding to the dataset; Step S6.2: Perform full matching verification of field definitions, primary key constraints, and index rules for the business table structure metadata, the data row record set, and the time-series change trajectory information; Step S6.3: Perform a full check on the full dataset of the business database after the table structure verification passes, including the business table structure metadata, data row record set, and time-series change trajectory information, to verify the number of records in the entire table, the values ​​of non-null fields, and the related foreign key constraints. Step S6.4: Perform a full verification of the data change sequence, business operation link, and time node matching degree of the full dataset of the business database, business table structure metadata, data row record set, and time sequence change trajectory information after the integrity verification passes. Step S6.5: Perform a compliance summary judgment on the full dataset of the business database after the flashback, the business table structure metadata, the data row record set, and the time-series change trajectory information that have passed the time-series consistency verification, and obtain the full dataset of the business database after the flashback that has passed the verification. Step S6.6: Perform database writing and status synchronization operations on the full dataset of the business database after the flashback that has passed the verification, and obtain the full dataset of the restored database.

[0025] Beneficial effects of steps S6.1 to S6.6: This series of steps completes multi-dimensional compliance verification of the data after flashback, establishes a fully automated data verification system, and solves the problems of insufficient consistency verification and inability to guarantee data availability after traditional data recovery. It covers multiple core verification dimensions such as table structure, data integrity, and business time sequence, closes the entire data flashback process, ensures the adaptability of the recovered data to the business operation requirements of the automated warehouse system, reduces the impact of data anomalies on subsequent warehousing operations, and reduces the cost and error of manual verification.

[0026] The process involves the following steps: Step S6.1 extracts the core metadata and business information of the recovered dataset to provide a basic reference for the entire process verification; Step S6.2 completes the matching verification of the table structure to ensure the structural compliance of the recovered data; Step S6.3 completes the full verification of data rows to ensure the integrity of the recovered data; Step S6.4 completes the consistency verification of business time sequence to ensure the matching of data with business links; Step S6.5 completes the summary judgment of all verification items to clarify the compliance status of the data; and Step S6.6 completes the formal writing and status synchronization of the verified data, outputting the usable full data of the recovered database.

[0027] To achieve the above objectives, this application also provides the following technical solutions: A data flashback device for an automated storage and retrieval system, the data flashback device being applied to the data flashback method described above, the data flashback device comprising: The automated storage and retrieval system data acquisition module is used to collect the full operation logs, business operation time sequence data, and data change trajectory sequences of the automated storage and retrieval system database. The multivariate time-series standardized dataset acquisition module is used to perform time-series alignment and standardized encoding on the full operation log, the business operation time-series data, and the data change trajectory sequence to generate a multivariate time-series standardized dataset. The abnormal data change event localization module is used to input the multivariate time-series standardized dataset into the PatchTST time-series anomaly detection algorithm to locate abnormal data change events and obtain a set of abnormal event time interval localization results. The target flashback execution plan acquisition module is used to input the abnormal event time interval location result set into the MOEA / D multi-objective optimization algorithm, and obtain the target flashback execution plan by matching the optimal recovery level and execution rules of Oracle flashback; The business database full data flashback module is used to perform flashback operations at the corresponding level according to the target flashback execution plan and generate a full dataset of the business database after flashback. The Flashback Business Data Verification Module is used to verify the full dataset of the Flashback Business Database. Once the verification is successful, the full dataset of the restored database is obtained.

[0028] To achieve the above objectives, this application also provides the following technical solutions: An electronic device includes a processor and a memory coupled to the processor, the memory storing program instructions executable by the processor; when the processor executes the program instructions stored in the memory, it implements the data flashback method of the automated storage and retrieval system as described above.

[0029] To achieve the above objectives, this application also provides the following technical solutions: A computer-readable storage medium storing program instructions that, when executed by a processor, enable the data flashback method of the automated storage and retrieval system described above. Attached Figure Description

[0030] Figure 1 This is a flowchart illustrating the steps of an embodiment of a data flashback method for an automated storage and retrieval system according to this application; Figure 2 This is a functional module diagram of an embodiment of a data flashback device for an automated storage and retrieval system according to this application; Figure 3 This is a schematic diagram of the structure of an embodiment of the electronic device of this application; Figure 4 This is a schematic diagram of the structure of one embodiment of the storage medium of this application. Detailed Implementation

[0031] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of the embodiments. Based on the embodiments of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of this application.

[0032] The terms "first," "second," and "third" in this application are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Therefore, a feature defined as "first," "second," or "third" may explicitly or implicitly include at least one of that feature. In the description of this application, "multiple" means at least two, such as two, three, etc., unless otherwise explicitly specified. All directional indications (such as up, down, left, right, front, back, etc.) in the embodiments of this application are only used to explain the relative positional relationships and movements between components in a specific orientation (e.g., as shown in the figures). If the specific orientation changes, the directional indications also change accordingly. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion. For example, a process, method, apparatus, product, or device that includes a series of steps or units is not limited to the listed steps or units, but may optionally include steps or units not listed, or may optionally include other steps or units inherent to these processes, methods, products, or devices.

[0033] In this document, the term "embodiment" means that a particular feature, structure, or characteristic described in connection with an embodiment may be included in at least one embodiment of this application. The appearance of this phrase in various places throughout the specification does not necessarily refer to the same embodiment, nor is it a mutually exclusive, independent, or alternative embodiment. It will be explicitly and implicitly understood by those skilled in the art that the embodiments described herein can be combined with other embodiments.

[0034] It should be noted that, due to the limited types and number of symbols or letters that can represent specific meanings, for embodiments with many formulas or codes, there may be situations where symbols or letters cannot meet the usage requirements. Therefore, the interpretation of formula symbols in the steps or sub-steps of the embodiments is only valid for the current step or sub-step.

[0035] If the same symbol has different interpretations in different steps or sub-steps, the interpretation in the current step or sub-step shall prevail; if the same symbol appears in different steps or sub-steps, but no interpretation is given in subsequent steps or sub-steps after its first appearance, the interpretation in the first step or sub-step shall be used.

[0036] like Figure 1 As shown, this embodiment provides an example of a data flashback method for an automated storage and retrieval system. In this embodiment, the data flashback method includes the following steps: Step S1: Collect the full operation logs, business operation time sequence data, and data change trajectory sequence of the automated storage and retrieval system database.

[0037] Preferably, this step provides basic data source support for the entire data flashback process of the automated storage and retrieval system, and its core function is to automatically collect, clean, and verify all operational data, business operation data, and data change data of the core database.

[0038] Furthermore, step S1 specifically includes the following steps: Step S1.1: Connect the standardized communication interface between the core database of the automated storage and retrieval system and the business execution system to establish a real-time channel for reading all data.

[0039] Preferably, the core interface targets are the main business database of the automated storage and retrieval system (AS / RS) running Oracle 11g or later, and four major business execution systems: the Warehouse Management System (WMS), the Warehouse Control System (WCS), the Stacker Crane Execution System, and the Conveyor Line Management System. The database side uses the standardized OCI (Oracle Call Interface) interface for interface connection, while the industrial equipment and business system side use the standardized OPCUA industrial communication interface. The communication protocol is TCP / IP, with the database using a fixed communication port of 1521 and the OPC UA service using a fixed port of 4840.

[0040] Preferably, the interface heartbeat interval is set to 100ms, the maximum number of timeout reconnections is 3, and the single reconnection interval is set to 500ms; the channel adopts a dual-link redundancy configuration, the main link is responsible for real-time data acquisition, and the backup link automatically switches after the main link has three consecutive heartbeat timeouts, with no data loss during the switching process.

[0041] Preferably, the permission configuration rule is to use read-only permissions for the entire reading channel, strictly following the principle of least privilege in the database. Only the execution permission of the SELECT statement and the read permission of the V$SESSION, V$LOG, and V$UNDOSTAT system views are granted. No write, modify, or delete permissions are granted to avoid interference with the business database during the data collection process.

[0042] Step S1.2: Continuously capture all running logs generated during database operation through the real-time full data reading channel.

[0043] Preferably, the log capture scope covers all core logs of the Oracle database, including five major categories: online redo logs, archive logs, alert logs, audit logs, and UNDO undo logs, fully covering the entire chain of database operation, transaction execution, and data changes.

[0044] Preferably, online redo logs and archived logs are captured and parsed in real time using the OracleLogMiner tool, with a capture frequency of 500ms / time and a single capture log block size of 1024KB; alarm logs and audit logs are captured in real time using file tail-tracking, with a capture interval of 1s / time; UNDO undo logs are read in real time through the V$UNDOSTAT view, with a reading interval consistent with the redo log capture frequency of 500ms / time.

[0045] Preferably, the log storage rule is that the captured raw logs are written to a local dedicated time-series storage partition in a time-series append manner. The partition reserves storage space of not less than 20% of the total capacity of the business database. The default retention period for raw logs is set to 90 days, which can be flexibly adjusted according to business compliance requirements.

[0046] Step S1.3: Synchronously collect business operation time-series data that matches the timeline of the full operation log through the full data real-time reading channel.

[0047] Preferably, the data collection scope covers time-series data of the entire business process of the automated storage and retrieval system, including inbound and outbound order operation records, inventory adjustment records, inventory count operation records, and storage location allocation records of the WMS system; equipment scheduling instruction records, task execution status records, and equipment action timing records of the WCS system; as well as real-time operating status data and task execution feedback data of end-effectors such as stacker cranes and conveyor lines.

[0048] Preferably, the system time of the business database server can be used as the globally unique time reference. All collected business operation time sequence data are bound to millisecond-level timestamps. The timestamps and the timestamps of the full running log captured in step S1.2 use the same reference, and the time synchronization error is controlled within ±10ms.

[0049] Preferably, the synchronous acquisition rule can adopt an incremental synchronous acquisition mode, which only acquires business operation data that completely overlaps with the time interval of the currently captured running log on the time axis. The acquisition frequency is strictly aligned with the log capture frequency, which is 500ms / time, to ensure that the business operation data matches the time axis of the database running log one by one without time misalignment.

[0050] Step S1.4: Capture the database data change trajectory sequence corresponding to the full operation log and business operation time sequence data through the full data real-time reading channel.

[0051] Preferably, the trajectory capture scope targets the core business tables of the automated warehouse, including the inventory master table, the location status table, the inbound and outbound document table, the equipment task table, and the user operation table. It captures all row-level data change records corresponding to INSERT, UPDATE, and DELETE operations. Each record contains five core fields: data before the change, data after the change, change timestamp, change operation user, and change transaction ID.

[0052] Preferably, the capture method can be based on the Oracle Flashback Transaction Query function, which associates the transaction ID captured in step S1.2 with the business operation time sequence data collected in step S1.3, and accurately captures the row-level data change trajectory within the corresponding time interval. The captured time interval is completely consistent with the time interval of the captured operation log and business operation data.

[0053] Preferably, each change track record is bound to a unique transaction ID, a millisecond-level timestamp, and a business operation order number, forming a strong correlation mapping with the database operation log and business operation time sequence data, ensuring that every data change can be traced back to the corresponding database transaction and business operation.

[0054] Step S1.5: Remove invalid null values ​​and duplicate data fragments from the full operation log, business operation time sequence data, and data change trajectory sequence.

[0055] Preferably, the removal of invalid null values ​​is as follows: (1) Full running log: Remove invalid log records with empty log content, empty transaction ID, or empty timestamp.

[0056] (2) Business operation time sequence data: Remove invalid operation records with empty operation order number, empty timestamp, empty device ID, or empty operation content.

[0057] (3) Data change trajectory sequence: Remove invalid change records where the transaction ID is empty, the change time is empty, or the data before and after the change is empty.

[0058] Preferably, for the removal of duplicate data fragments, a two-dimensional deduplication rule of "primary key + millisecond-level timestamp" can be adopted. The duplicate judgment threshold is that records with the same primary key field, the same millisecond-level timestamp, and completely identical content fields are judged as duplicate data, and only the earliest record is retained, while the rest of the duplicate fragments are removed. The deduplication process adopts a sliding window mode with a window size set to 10 seconds, and processes all the data in the current window at a time to ensure that no duplicate data remains.

[0059] Step S1.6: Output the full running log, business operation time sequence data, and data change trajectory sequence that have been verified.

[0060] Preferably, for data validity verification, a two-dimensional verification can be performed. The first is time interval coverage verification, which requires that within the same statistical time window, the time matching degree of the full operation log, business operation time series data, and data change trajectory sequence is not less than 99.5%. The second is correlation matching degree verification, which requires that the correlation matching degree of the transaction ID and business order number of the three types of data is not less than 99%.

[0061] Preferably, after verification, the three types of data are sorted in ascending order according to a unified timeline and output to the standardized processing stage of the subsequent S2 step; at the same time, the original collected data, cleaned data, and verification results are synchronously written to local backup storage, and the backup retention period is consistent with the original log retention period, which is 90 days.

[0062] Preferably, if data verification fails, the data supplementation process is automatically triggered. For time intervals with missing data or substandard matching, the log capture, data collection, and trajectory capture operations are re-executed through the established real-time full data reading channel until the data verification is successful before output.

[0063] Beneficial effects of steps S1.1 to S1.6: This series of steps establishes a stable and compliant data acquisition link for the data flashback process of the automated storage and retrieval system, enabling multi-dimensional operation of the core database and automated acquisition and basic verification of business data. It ensures the integrity and consistency of the data source, avoids problems such as misalignment of time sequences of multi-source data and interference from invalid data, provides compliant and usable basic data support for the entire data flashback process, and adapts to the real-time data acquisition needs during the continuous operation of the system.

[0064] The process includes the following steps: Step S1.1: Establishing a standardized data transmission channel between the system and the database to ensure the compliance and stability of the data collection process; Step S1.2: Continuously capturing database operation logs to provide basic support for end-to-end data traceability; Step S1.3: Synchronously collecting business operation data to ensure the temporal matching of operation data and business data; Step S1.4: Obtaining database data change trajectory information to provide original evidence for data anomaly tracing; Step S1.5: Performing basic cleaning of the raw data to remove invalid data fragments and improve the usability of the basic data; and Step S1.6: Outputting the verified basic data to complete the closed-loop management of the data collection process.

[0065] Step S2 involves performing time-series alignment and standardized encoding on the full runtime logs, business operation time-series data, and data change trajectory sequences to generate a multivariate time-series standardized dataset.

[0066] Preferably, this step is the core preprocessing stage of the data flashback process. It takes the full-volume operation logs, business operation time-series data, and data change trajectory sequences that have been verified and output from step S1 or step S1.6. Through time-series normalization, encoding conversion, and standardization, it eliminates the problems of time-series misalignment, inconsistent formats, and differences in units of multi-source heterogeneous data, and finally outputs a multivariate time-series standardized dataset that meets the input requirements of the PatchTST time-series anomaly detection algorithm.

[0067] Furthermore, step S2 specifically includes the following steps: Step S2.1: Obtain the full running logs, business operation time sequence data, and data change trajectory sequence, and extract the set of native timestamp fields corresponding to each data dimension.

[0068] Preferably, the data source takes the valid dataset output from the strictly locked step S1.6 as the only input, and all three types of data are bound to the millisecond-level native Unix timestamp consistent with the global benchmark in step S1, without any prior modification or truncation operations, to ensure the originality of the time series benchmark.

[0069] Preferably, the extraction scope of the native timestamp field targets the core time-series attributes of the three types of data, and specifically extracts the immutable native timestamp field, including the following data fields: (1) Full runtime log: transaction commit timestamp COMMIT_TIMESTAMP, log write timestamp LOG_CREATE_TIMESTAMP.

[0070] (2) Business operation timing data: operation initiation timestamp OP_START_TIMESTAMP, operation completion timestamp OP_END_TIMESTAMP.

[0071] (3) Data change trajectory sequence: row-level change execution timestamp CHANGE_EXEC_TIMESTAMP.

[0072] Preferably, for the construction of the timestamp field set, all extracted timestamp fields can be classified according to data source to construct a structured native timestamp field set. Each record in the set contains four core attributes: "field name, data category, time precision, and legal value range". A metadata description file is generated synchronously as the sole benchmark for subsequent time-series alignment.

[0073] Preferably, a dual threshold verification mechanism can be set: first, the timestamp value must fall between the start time T_start and the end time T_end of the acquisition window; second, the validity rate of the timestamp of a single batch of data is not less than 99.9%; invalid records that exceed the threshold are directly marked, and the targeted supplementary acquisition process of S1 is triggered synchronously until the verification is passed.

[0074] Step S2.2: Perform time-series alignment on all data dimensions of the original timestamp field set based on a unified time granularity to obtain the full runtime log, business operation time-series data, and data change trajectory sequence after time-series alignment.

[0075] Preferably, the setting of the unified time granularity can be combined with the minimum time interval of the automated storage and retrieval system's business operations and the input requirements of the subsequent PatchTST algorithm, and the unified time step Δt can be fixed at 100ms to ensure that all data dimensions have a completely consistent number of sampling points on the same time axis.

[0076] Preferably, the standard time axis can be acquired using the window start time T_start as the reference zero point to generate an equally spaced standard time axis sequence, calculated using the formula T. i =T start +i×Δt(i=0,1,2,...,N-1). Where N is the total number of sampling points within the time window, N=⌈(T end -T start ) / Δt⌉, ⌈⌉ is the floor function, and this time axis is the unique alignment reference for the entire process.

[0077] Preferably, an appropriate alignment method can be adopted for the characteristics of different data types to avoid the loss of timing information: (1) Event-type discrete data (full running log, data change trajectory sequence): the nearest neighbor matching method is used to match the original record to the standard time axis sampling point closest to its original timestamp. The matching threshold is set to ±50ms. Records exceeding the threshold are stored in the edge event buffer and do not participate in the main process alignment.

[0078] (2) Continuous time series data (business operation time series data): linear interpolation method is used for resampling and alignment to ensure that continuous state data has corresponding values ​​at each standard time step. It is worth noting that linear interpolation method is a mature existing technology, and the specific calculation process will not be described in this embodiment.

[0079] Preferably, after alignment, the effective coverage of the core data dimension of each sampling point on the standard time axis is verified, requiring the coverage to be no less than 99%. Time intervals below the threshold trigger a second sampling and alignment operation.

[0080] Step S2.3: Perform a mapping conversion from unstructured data to structured numerical data on the time-aligned full operation logs, business operation time-series data, and data change trajectory sequences to obtain structured encoded full operation logs, business operation time-series data, and data change trajectory sequences.

[0081] Preferably, for the formulation of a categorized encoding strategy, encoding conversion rules without information loss can be formulated for the field types of the aligned data to ensure that all data can be converted into a numerical format that the algorithm can process: (1) Continuous numerical fields: including equipment operating parameters, time intervals, transaction statistics, etc., are directly and uniformly converted to float64 format, retaining the original numerical information.

[0082] (2) Finite enumeration type fields: including operation type, event level, device status, transaction status, etc., are mapped to continuous integers using ordinal encoding, with an encoding range of [0, n-1] (n is the total number of enumeration values ​​of the field), preserving the ordered logical relationship between categories.

[0083] (3) Unstructured text fields: including log details, operation notes, change descriptions, etc. Word embedding encoding is performed using the Word2Vec model pre-trained in the industrial warehousing field. The model is trained based on 1 million business logs from the same industry. The word vector dimension is fixed at 32 dimensions, and a single text is converted into a fixed-length 32-dimensional numerical vector.

[0084] Preferably, for the solidification of encoding rules, a unique encoding mapping dictionary can be generated for each field, containing core information such as "field name, original value, and encoded value". The dictionary is stored in a fixed manner throughout the process to ensure that the encoding rules of the same field remain consistent throughout the entire process and there is no encoding drift problem.

[0085] Preferably, a reverse mapping verification mechanism can be adopted, randomly selecting no less than 10% of the encoded data to perform reverse restoration, requiring the original content and the restored content to match 100% to ensure that no information is lost during the encoding conversion.

[0086] Step S2.4: Perform global numerical standardization on the structured encoded full operation log, business operation time series data, and data change trajectory sequence to obtain full operation log, business operation time series data, and data change trajectory sequence with unified dimensions.

[0087] Preferably, the standardization method can be the Z-Score zero-mean standardization method, which eliminates the differences in dimensionality and numerical range between different data dimensions, so that all feature dimensions conform to the standard normal distribution with a mean of 0 and a standard deviation of 1, which is fully compatible with the input distribution requirements of the PatchTST algorithm.

[0088] Preferably, for the fixed rules of statistics: μ and σ are fixed throughout the process after offline calculation based on historical normal datasets and are not updated with single batches of data during online processing to avoid the impact of data distribution drift on the standardization effect. μ is the global mean of this feature dimension in the historical 90 days of normal business data, and σ is the corresponding global standard deviation.

[0089] Preferably, extreme values ​​exceeding the 3σ range after standardization can be truncated, limiting the values ​​to the [-3,3] interval to avoid interference from extreme values ​​with subsequent anomaly detection algorithms. The mean deviation of all feature dimensions after standardization is verified to be no more than ±0.1, and the standard deviation deviation is no more than ±0.2, ensuring that the standardization effect meets the requirements.

[0090] Step S2.5: The full-scale operation logs, business operation time-series data, and data change trajectory sequences with unified dimensions are spliced ​​and integrated along the same time axis to obtain a multi-dimensional time-series standardized dataset.

[0091] Preferably, the standard time axis generated in step S2.2 is used as the sole reference, and the time sampling points T are used as the basis for the calculation. i The ascending order of the sampling points is used to horizontally concatenate all feature dimensions at the same sampling point, with each time sampling point corresponding to a fixed-length multidimensional feature vector.

[0092] The total number of feature dimensions for a fixed single-time sampling point is 84, and the specific dimension allocation is as follows: (1) Full runtime log features: 32-dimensional text embedding features + 8-dimensional log statistical features, for a total of 40 dimensions.

[0093] (2) Business operation time sequence data characteristics: 16-dimensional device status characteristics + 12-dimensional business operation characteristics, for a total of 28 dimensions.

[0094] (3) Data change trajectory sequence features: 10-dimensional change statistical features + 6-dimensional change type coding features, a total of 16 dimensions are spliced ​​together to form a two-dimensional multivariate time series array with shape [N,84] (N is the total number of sampling points), which fully matches the input format requirements of the PatchTST algorithm.

[0095] Preferably, a few missing values ​​in the spliced ​​dataset are filled using forward fill, resulting in a missing value rate of 0 in the dataset after filling, ensuring that the feature dimensions of all time sampling points are complete.

[0096] Preferably, the concatenated dataset can be converted into NumPy array format, and a metadata file can be generated simultaneously, containing core information such as feature dimension names, time window ranges, sampling step size, and total number of sampling points, for parameter matching in subsequent algorithm processing.

[0097] Beneficial effects of steps S2.1 to S2.5: This series of steps completes the time-series regularization and standardization of multi-source heterogeneous data after collection, solving the problems of misaligned time sequences, inconsistent formats, and large dimensional differences in the original data. It enables the same baseline management of multi-dimensional business and operational data, provides well-suited input data for subsequent anomaly detection algorithms, reduces the error risk of subsequent data processing, ensures the continuity and consistency of data processing throughout the entire process, and adapts to the multi-source data processing needs of automated storage and retrieval systems.

[0098] The process includes the following steps: Step S2.1 extracts the native timestamp fields of each data dimension to provide a unified benchmark for the entire time-series processing; Step S2.2 performs time-series alignment of multi-source data to eliminate time-series deviations between different data dimensions and ensure the temporal correlation between data; Step S2.3 converts unstructured data into structured numerical data, unifies the format of multi-source data, and improves data processability; Step S2.4 performs global numerical standardization to eliminate the differences in units of measurement between different data dimensions and reduce interference factors in subsequent algorithm processing; and Step S2.5 performs coaxial integration of multi-dimensional data and outputs a standardized dataset that meets the requirements of subsequent processing, thus achieving a closed loop in the data preprocessing process.

[0099] Step S3: Input the multivariate time-series standardized dataset into the PatchTST time-series anomaly detection algorithm to locate abnormal data change events and obtain the result set of abnormal event time interval location.

[0100] Preferably, this step relies on the PatchTST (Patch Time Series Transformer) time series anomaly detection algorithm, takes the multivariate time series standardized dataset output from step S2 or step S2.5, and completes the accurate time interval location of abnormal data change events through sequence block encoding, global time series dependency modeling, data reconstruction, residual calculation and anomaly judgment.

[0101] Preferably, for steps involving algorithms, this embodiment introduces pseudocode for auxiliary explanation.

[0102] Furthermore, step S3 specifically includes the following steps: Step S3.1: Obtain the multivariate time-series standardized dataset and extract the corresponding time axis index sequence and multidimensional feature sequence.

[0103] Preferably, the data source accepts a NumPy array of shape [N, 84] output from step S2 or step S2.5 as the only input (N is the total number of sampling points on the standard time axis, and 84 is the fixed number of feature dimensions), and performs dual format verification: first, it verifies that the array has no abnormal values ​​such as NaN and Inf, and the abnormal value rate must be 0; second, it verifies that the number of feature dimensions is strictly 84, and the dimension deviation must be 0. If the verification fails, the re-splicing process of S2 is triggered.

[0104] Preferably, the time axis index sequence is generated as follows: Based on the standard time axis generated in step S2.2, a corresponding integer index sequence I=[0,1,2,...,N-1] is generated synchronously, and the index is related to the standard time axis sampling point T. i One-to-one correspondence, the index sequence serves as the reference for the position of subsequent sequence blocks.

[0105] Multi-dimensional feature sequence decomposition: The input two-dimensional array is expanded along the time dimension to generate a set of multi-dimensional feature sequences at a single time step, where each element is an 84-dimensional feature vector X corresponding to index i. i ∈R84, fully preserving the temporal order and feature dimension information of the original data.

[0106] For example, this step can be implemented using the following pseudocode: import numpy as np def extract_time_feature(multivariate_data): # Format validation assert not np.isnan(multivariate_data).any(), "The dataset contains NaN values." assert multivariate_data.shape[1] == 84,"Feature dimension mismatch" # Generate timeline index sequence N = multivariate_data.shape[0] time_index = np.arange(N) # Splitting multi-dimensional feature sequences feature_sequences = [multivariate_data[i, :] for i in range(N)] return time_index, feature_sequences, multivariate_data Step S3.2: Input the time axis index sequence and multi-dimensional feature sequence into the PatchTST time anomaly detection algorithm, and generate a block-embedded feature sequence with position information through sequence segmentation and position encoding operations.

[0107] Preferably, the PatchTST sequence segmentation strategy adopts a fixed-length sliding window segmentation method. The core parameters are configured as follows: patch length P=16 (corresponding to a 1.6s time span, since a single time step Δt=100ms), sliding step size S=8 (corresponding to a 0.8s sliding interval), and number of blocks M=⌊(NP) / S⌋+1. Here, ⌊⌋ is a floor function, and each patch contains 84-dimensional features across 16 consecutive time steps, forming a local temporal segment with shape [P, 84].

[0108] Preferably, for block embedding mapping, the two-dimensional features of each patch can be mapped to a fixed-dimensional vector through a learnable linear projection layer, with a projection dimension dmodel=128, that is, each patch is converted into a d... model The dimensional embedding vector fully preserves local temporal features while reducing computational complexity.

[0109] Preferably, a learnable position embedding can be added to each patch embedding vector, with the position embedding dimension being the same as the patch embedding dimension, d. model The position index range is [0, M-1]. The temporal order information between patches is preserved through position encoding, avoiding the insensitivity of Transformer to temporal position.

[0110] Patch embedding and positional encoding fusion: The patch embedding vector is added element-wise to the corresponding positional embedding vector to generate the final patch embedding feature sequence with positional information, in shape [M,d]. model ], which serves as the input for the subsequent Transformer encoder.

[0111] For example, this step can be implemented using the following pseudocode: import torch import torch.nn as nn class PatchEmbedding(nn.Module): def __init__(self, patch_len=16, stride=8, d_model=128, feat_dim=84): super().__init__() self.patch_len = patch_len self.stride = stride # Linear projection layer: [patch_len, feat_dim] -> d_model self.projection = nn.Linear(patch_len * feat_dim, d_model) # Learnable Position Embedding self.position_embedding = nn.Parameter(torch.randn(1000, d_model)) # Default maximum number of patches: 1000 def forward(self, x): # x-shape: [batch_size, N, feat_dim], where batch_size=1 batch_size, N, feat_dim = x.shape # Sequence segmentation: [batch_size, N, feat_dim] -> [batch_size, M, patch_len*feat_dim] patches = x.unfold(dimension=1, size=self.patch_len, step=self.stride) patches = patches.contiguous().view(batch_size, -1, self.patch_len * feat_dim) # Chunking patch_emb = self.projection(patches) # [batch_size, M, d_model] # Add location encoding M = patch_emb.shape[1] pos_emb = self.position_embedding[:M, :].unsqueeze(0) # [1, M, d_model] return patch_emb + pos_emb Step S3.3: Input the block-embedded feature sequence into the Transformer encoder layer of the PatchTST temporal anomaly detection algorithm to perform global temporal dependency modeling and calculation, and obtain the global temporal feature representation sequence.

[0112] Preferably, the Transformer encoder structure is configured with a 4-layer (L=4) stacked Transformer encoder structure, with each encoder layer containing two core sub-layers: a multi-head self-attention sub-layer and a feedforward network sub-layer. The core parameters are configured as follows: (1) Multi-head self-attention: number of heads h=8, dimension d of each head k =d model / h=16, attention dropout rate p attn =0.1.

[0113] (2) Feedforward Network (FFN): Hidden layer dimension d ff =512, GELU activation function, FFN dropout rate p ffn =0.1.

[0114] (3) Layer normalization can adopt a Pre-LN structure, that is, layer normalization is performed before each sub-layer and residual connection is performed after each sub-layer. The layer normalization epsilon parameter ϵ=10 -6 .

[0115] Preferably, multi-head self-attention computation can capture long-distance temporal dependencies between patches through a multi-head self-attention mechanism. The attention weight calculation covers all patch positions, without being limited to a local window, and fully models global temporal relationships. The attention calculation formula is as follows: Where Q, K, and V are the query, key, and value matrices obtained by linear projection of the block embedding features, and T is the transpose.

[0116] Preferably, for the forward propagation of the encoder, the block-embedded feature sequence is passed sequentially through 4 layers of Transformer encoders, and the feature dimension of the output of each layer is maintained at d. model =128 remains unchanged, and the final output of the 4th layer encoder is the global temporal feature representation sequence with shape [M,d]. model It fully integrates local temporal features and global dependencies.

[0117] For example, this step can be implemented by the following pseudocode: class TransformerEncoderLayer(nn.Module): def __init__(self, d_model=128, n_heads=8, d_ff=512, dropout=0.1): super().__init__() self.self_attn = nn.MultiheadAttention(d_model, n_heads, dropout=dropout, batch_first=True) self.ffn = nn.Sequential( nn.Linear(d_model, d_ff), nn.GELU(), nn.Dropout(dropout), nn.Linear(d_ff, d_model), nn.Dropout(dropout) ) self.norm1 = nn.LayerNorm(d_model, eps=1e-6) self.norm2 = nn.LayerNorm(d_model, eps=1e-6) def forward(self, x): # Pre-LN + Residual connection attn_output, _ = self.self_attn(self.norm1(x), self.norm1(x),self.norm1(x)) x = x + attn_output ffn_output = self.ffn(self.norm2(x)) x = x + ffn_output return x class TransformerEncoder(nn.Module): def __init__(self, num_layers=4, d_model=128, n_heads=8, d_ff=512,dropout=0.1): super().__init__() self.layers = nn.ModuleList([ TransformerEncoderLayer(d_model, n_heads, d_ff, dropout) for _ in range(num_layers) ]) def forward(self, x): for layer in self.layers: x = layer(x) return x Step S3.4: Perform reverse reconstruction calculation of the time-series dimension on the global time-series feature representation sequence to obtain a reconstructed time-series dataset that matches the dimension of the multivariate time-series standardized dataset.

[0118] Preferably, the reconstruction head structure design can adopt a reconstruction strategy of linear projection + overlapping region averaging. The reconstruction head contains two core parts: one is a linear projection layer, which represents each d of the global temporal feature representation sequence. model The first layer maps the dimensional vector back to the patch features of dimension [P,84]; the second layer is the overlapping region averaging layer, which takes the average of the reconstruction values ​​of the same time step covered by multiple patches to eliminate the inconsistency of the overlapping region, in response to the overlapping time step caused by sliding blocks.

[0119] Preferably, linear projection reconstruction can be performed using a learnable linear projection layer to reconstruct a shape of [M,d]. model The global temporal feature representation sequence is mapped to a set of reconstruction patches of shape [M,P,84], where each reconstruction patch corresponds to the time interval of the original block.

[0120] Preferably, for average aggregation of overlapping regions, all reconstructed patches can be placed back onto the standard time axis according to their time positions. For time steps covered by multiple patches (since the sliding step size S=8<P=16, each intermediate time step is covered by 2 patches), the arithmetic mean of all reconstructed values ​​is calculated as the final reconstructed value of that time step. For the start and end time steps covered by only 1 patch, their reconstructed values ​​are directly taken.

[0121] Preferably, the aggregated dataset generates a reconstructed time series dataset with shape [N, 84], which is completely consistent with the dimensions of the multivariate time series normalized dataset input in step S3.1, ensuring the feasibility of subsequent residual calculation.

[0122] For example, this step can be implemented using the following pseudocode: class ReconstructionHead(nn.Module): def __init__(self, d_model=128, patch_len=16, feat_dim=84): super().__init__() self.patch_len = patch_len self.feat_dim = feat_dim # Linear projection: d_model -> patch_len * feat_dim self.projection = nn.Linear(d_model, patch_len * feat_dim) def forward(self, global_feat, N, stride=8): # global_feat shape: [batch_size, M, d_model], batch_size=1 batch_size, M, _ = global_feat.shape # Projecting back to patch features: [batch_size, M, patch_len*feat_dim] -> [batch_size, M, patch_len, feat_dim] recon_patches = self.projection(global_feat).view(batch_size, M,self.patch_len, self.feat_dim) # Initialize and reconstruct the dataset and counting matrix recon_data = torch.zeros(batch_size, N, self.feat_dim, device=global_feat.device) count = torch.zeros(batch_size, N, self.feat_dim, device=global_feat.device) # Put the patch back onto the timeline and accumulate it for i in range(M): start = i * stride end = start + self.patch_len recon_data[:, start:end, :] += recon_patches[:, i, :, :] count[:, start:end, :] += 1 # Average of overlapping areas recon_data = recon_data / torch.clamp(count, min=1) return recon_data Step S3.5: Perform point-by-point residual calculation on the reconstructed time series dataset and the multivariate time series standardized dataset to generate a time series residual sequence.

[0123] Preferably, the residual calculation rule is as follows: using the absolute residual calculation method, for each time step i (corresponding to the index 0≤i<N) on the standard time axis, the original feature vector X is calculated. i The absolute difference between the reconstructed feature vector X^i and the feature vector X^i is used to generate an 84-dimensional residual vector R for that time step. i The calculation formula is: Where |·| represents the absolute value operation for each element.

[0124] Preferably, for the construction of the time-series residual sequence, the residual vectors of all time steps can be arranged in ascending order by time index to generate a time-series residual sequence of shape [N, 84], which fully preserves the reconstruction error information of each feature dimension, and the time axis of the residual sequence is completely consistent with the original data and the reconstructed data.

[0125] Preferably, all values ​​in the verification residual sequence are non-negative, the non-negativity rate must be 100%, and the dimension of the verification residual sequence must be completely consistent with the original data, with a dimension deviation of 0, to ensure that the residual sequence can be used for subsequent anomaly detection.

[0126] For example, this step can be implemented using the following pseudocode: def compute_residual(original_data, recon_data): # Convert to NumPy array (if it's a Torch tensor) if isinstance(original_data, torch.Tensor): original_data = original_data.detach().cpu().numpy() if isinstance(recon_data, torch.Tensor): recon_data = recon_data.detach().cpu().numpy() # Point-by-point absolute residual calculation residual = np.abs(original_data - recon_data) # Validity Validation assert (residual>= 0).all(),"The residual sequence contains negative values" assert residual.shape == original_data.shape, "Residual sequence dimensions do not match" return residual Step S3.6: Perform adaptive anomaly threshold determination and continuous time interval aggregation on the time-series residual sequence to locate the boundary of abnormal data change events, and obtain the abnormal event time interval location result set.

[0127] Preferably, the adaptive anomaly threshold calculation can use the Exponentially Weighted Moving Average (EWMA) method to dynamically update the anomaly threshold for each feature dimension, with the core parameters configured as follows: (1) Initial threshold τ0: determined based on the 99th quantile of the residuals of 90 days of historical normal business data, i.e., τ0 = Q 99 (R history ).

[0128] (2) The smoothing coefficient α = 0.1 controls the sensitivity of threshold update.

[0129] (3) Single time step threshold update formula: τ t =α×R t +(1-α)×τ t-1 , where R t The feature dimension residual is the current time step.

[0130] (4) Final anomaly detection threshold τ finalThe maximum value of the threshold for all feature dimensions can be taken to ensure that outliers for all feature dimensions are covered.

[0131] Preferably, for single-time-step anomaly detection, the maximum absolute value R of the residual vector can be calculated for each time step i. i,max =max(R i If R i,max >τ final If the time step is normal, it is considered an abnormal time point and marked as 1; otherwise, it is considered a normal time point and marked as 0, generating a binary abnormal marker sequence L=[l0,l1,...,l...]. N-1 ], where l i ∈{0,1}.

[0132] Preferably, for aggregation of continuous time intervals, a sliding window aggregation method can be used, with a window size W=5 (corresponding to a 500ms time span). If there are 5 or more consecutive anomalous time points in the binary anomaly marker sequence (i.e., consecutive l... i If the interval is 1 and its length is ≥ W, then it is aggregated into an abnormal event time interval, and the starting time index i of the interval is recorded. start and end time index i end T corresponds to the standard time axis i_start and T i_end .

[0133] Preferably, for the generation of the abnormal event time interval location result set, all aggregated abnormal event time intervals can be arranged in ascending order of start time to generate the final abnormal event time interval location result set. Each result contains core information such as "start timestamp, end timestamp, interval length (number of time steps)", with no overlapping intervals and no time misalignment.

[0134] For example, this step can be implemented using the following pseudocode: def adaptive_threshold_detection(residual, tau0, alpha=0.1, window_size=5): N, feat_dim = residual.shape # Initialize threshold tau = np.ones(feat_dim) * tau0 anomaly_labels = np.zeros(N) # Update the threshold and make a judgment on a time-step basis for i in range(N): r_i = residual[i, :] # Update the EWMA threshold for each feature dimension tau = alpha * r_i + (1 - alpha) * tau # Calculate the final decision threshold tau_final = np.max(tau) # Single Time Step Anomaly Detection r_max = np.max(r_i) if r_max>tau_final: anomaly_labels[i] = 1 # Aggregation of Continuous Time Intervals anomaly_intervals = [] current_start = None for i in range(N): if anomaly_labels[i] == 1: if current_start is None: current_start = i else: if current_start is not None: if i - current_start>= window_size: anomaly_intervals.append((current_start, i-1)) current_start = None # Handling the exception range at the end if current_start is not None and N - current_start>= window_size: anomaly_intervals.append((current_start, N-1)) return anomaly_intervals Beneficial effects of steps S3.1 to S3.6: This series of steps relies on time-series anomaly detection algorithms to accurately identify and locate anomalies in standardized datasets, solving the problems of insufficient accuracy and ambiguous boundaries in existing technologies for locating data anomalies. It mines deep anomaly features in time-series data, providing accurate time intervals for subsequent recovery plan formulation. It adapts to the automated identification needs of data anomalies during the continuous operation of automated storage and retrieval systems, reducing the cost and error of manual investigation and improving the efficiency and accuracy of anomaly event location.

[0135] The process involves the following steps: Step S3.1 extracts the timeline index and multi-dimensional feature sequences corresponding to the dataset, providing a basic temporal and feature reference for subsequent algorithm processing; Step S3.2 completes sequence segmentation and position encoding, preserving the positional correlation information of the time-series data and enhancing the identifiability of the time-series features; Step S3.3 completes global temporal dependency modeling, mining deep correlation features between data, and improving the sensitivity of anomaly identification; Step S3.4 completes reverse reconstruction calculation of the time-series dimension, generating a reference dataset that matches the original data dimension; Step S3.5 completes point-by-point residual calculation, quantifying the deviation between the original data and the reconstructed data, providing a quantitative basis for anomaly judgment; and Step S3.6 completes anomaly threshold judgment and interval aggregation, realizing the boundary location of abnormal events and outputting clear time interval results for abnormal events.

[0136] Step S4: Input the abnormal event time interval location result set into the MOEA / D multi-objective optimization algorithm, and obtain the target flashback execution plan by matching the optimal recovery level and execution rules of Oracle flashback.

[0137] Preferably, this step is the core decision-making stage of the data flashback process. It takes the abnormal event time interval location result set output by step S3 or step S3.6, completes multi-objective optimization solution based on MOEA / D (Multi-objective Evolutionary Algorithm based on Decomposition), matches the standard recovery level and execution rules of Oracle flashback technology, and outputs a target flashback execution plan that takes into account recovery accuracy, execution efficiency, and business impact.

[0138] Preferably, for steps involving algorithms, this embodiment introduces pseudocode for auxiliary explanation.

[0139] Furthermore, step S4 specifically includes the following steps: Step S4.1: Obtain the result set of abnormal event time interval location and construct the decision variable space, constraint set, and optimization objective function set adapted to the MOEA / D multi-objective optimization algorithm.

[0140] Preferably, the data source accepts the set of abnormal event time interval location results output from the strict locking step S3 or step S3.6 as the sole input, and each abnormal interval includes a start timestamp T. s End timestamp T e Interval duration ΔT abn Perform dual validity checks: first, check T. s <T e Furthermore, the interval must fall within the original data acquisition window; secondly, the business tables and transaction records associated with the abnormal interval must be verified to be complete and traceable. If the verification fails, the abnormal event re-judgment process in step S3 will be triggered.

[0141] Preferably, for the construction of the decision variable space, a 4-dimensional decision variable vector x=[x1,x2,x3,x4] is constructed using the configurable parameters of Oracle Flashback technology as the core, clarifying the legal value range and physical meaning of each variable, thus forming the decision variable space Ω: (1) x1: Oracle Flashback Recovery Level, discrete enumeration type, encoded as integers 0-5, corresponding to Oracle official standard recovery levels: 0=Flashback Query, 1=Flashback Version Query, 2=Flashback Transaction Query, 3=Flashback Table, 4=Flashback Delete, 5=Flashback Database.

[0142] (2) x2: Flashback target time node, continuous type, with a value range of [Ts-3600s, Ts] (1 hour before the start of the exception to the start point of the exception), in seconds, corresponding to Unix millisecond-level timestamps.

[0143] (3) x3: The range of data to be restored, discrete enumeration type, encoded as integers 0-2, corresponding to: 0 = only abnormal row-level data, 1 = all data of abnormal related business tables, 2 = all database data.

[0144] (4) x4: Execution timing mode, discrete enumeration type, encoded as integers 0-1, corresponding to: 0=offline shutdown execution, 1=online hot standby execution.

[0145] Preferably, the construction of the constraint set can be combined with the business continuity requirements of the automated storage and retrieval system and the Oracle flashback technology specification to construct a set of hard constraints C, in which all optimization individuals must 100% satisfy the hard constraints: (1) Time constraint: x2 < Ts, the flashback target time must be earlier than the start time of the abnormal event.

[0146] (2) Hierarchical adaptation constraint: when ΔT abn When x1 ≥ 3, the use of query-only recovery level is prohibited when x1 > 86400s (24 hours).

[0147] (3) Execution mode constraint: When x4=1 (online execution), x1≠5 (flashback database must be stopped for execution).

[0148] (4) Scope Coverage Constraint: The recovery scope corresponding to x3 must fully cover all business tables and data rows involved in the abnormal event.

[0149] Preferably, for constructing the set of optimization objective functions, three minimization objectives can be set, with no preset priority, to adapt to the solution requirements of the MOEA / D multi-objective optimization algorithm. The objective function formula is as follows: (1) Objective 1: Minimize the data recovery error f1(x), and the calculation formula is f1(x)=1-η, where η is the matching degree between the recovered data and the normal business data before the anomaly, and the value range is [0,1].

[0150] (2) Objective 2: Minimize the total execution time f2(x) of the recovery, in seconds. The calculation formula is f2(x)=S×β(x1), where S is the total amount of data to be recovered (unit: GB), and β(x1) is the single GB standard execution time coefficient of the corresponding recovery level, with the following values: β(0-2)=5s / GB, β(3)=12s / GB, β(4)=8s / GB, β(5)=60s / GB.

[0151] (2) Objective 3: Minimize the business impact f3(x), with a value range of [0,1], and the calculation formula is f3(x)=0.6×ω stop +0.3×ω range +0.1×ω level , where ω stop The standardized coefficient for downtime, ω range To restore the range standardization coefficient, ω level To restore the hierarchical complexity standardization coefficient.

[0152] For example, this step can be implemented using the following pseudocode: def build_moead_framework(anomaly_intervals): # Extracting core parameters of outlier intervals T_s = anomaly_intervals[0][0] T_e = anomaly_intervals[0][1] delta_T_abn = T_e - T_s # 1. Constructing the decision variable space decision_space = { "x1": {"type":"discrete","range": [0,1,2,3,4,5]}, "x2": {"type":"continuous","range": [T_s - 3600, T_s]}, "x3": {"type":"discrete","range": [0,1,2]}, "x4": {"type":"discrete","range": [0,1]} } # 2. Construct a set of hard constraints def hard_constraints(x): if x[2]>= T_s: return False if delta_T_abn>86400 and x[0]<3: return False if x[3] == 1 and x[0] == 5: return False return True # 3. Constructing the set of optimization objective functions def objective_functions(x): f1 = 1 - calc_match_degree(x) f2 = calc_data_size(x) * get_beta_coef(x[0]) f3 = calc_business_impact(x) return [f1, f2, f3] return decision_space, hard_constraints, objective_functions Step S4.2: Input the decision variable space, constraint set, and optimization objective function set into the MOEA / D multi-objective optimization algorithm, and generate the initialized MOEA / D multi-objective optimization algorithm population and weight vector set through algorithm population initialization and uniform weight vector distribution operations.

[0153] Preferably, for the core parameter configuration of the MOEA / D algorithm, the standard MOEA / D algorithm framework can be adopted, with fixed general optimization parameters for industrial scenarios: population size N=100, number of optimization targets m=3, neighborhood size T=20, differential evolution crossover probability CR=0.9, mutation scaling factor F=0.5, and maximum number of iterations G. max =200, the iteration termination convergence threshold is when the Pareto solution set has not been updated for 20 consecutive generations.

[0154] Preferably, the uniform distribution of weight vectors can be achieved using a simplex lattice design to generate uniformly distributed weight vectors, resulting in N=100 3D weight vectors, λ i =(λ 1i , λ 2i , λ 3i ), satisfying λ 1i +λ 2i +λ 3i =1 and λ ji ≥0, the weight vector uniformly covers the unit simplex of the 3D target space, avoiding blind spots in the solution space search.

[0155] Preferably, for the construction of neighborhood relationships, each weight vector λ can be... i Calculate the Euclidean distance between it and all other weight vectors, take the indices of the 20 nearest weight vectors T, and form the neighborhood set B(i) of the weight vector. Finally, generate the global neighborhood set B={B(1),B(2),...,B(N)}, which is used for subsequent neighborhood update operations.

[0156] Preferably, for population initialization, N initial individuals x that satisfy all hard constraints can be randomly generated within the decision variable space Ω. 1 ,x 2 ,...,x N Each individual corresponds to a set of valid decision variable vectors; for each initial individual, calculate its corresponding three objective function values ​​F(x). i )=[f1(x i ),f2(x i ),f3(x i Simultaneously initialize the global reference point z*=[z1*,z2*,z3*], where z j *=min{F(x i ) j |i=1,2,...,N}, that is, the current minimum value of each target dimension, which serves as the benchmark for subsequent Chebyshev aggregation calculations.

[0157] Preferably, the hard constraint satisfaction rate of all initial individuals is ensured to be 100%. Individuals that do not meet the constraints are regenerated until the entire population meets the requirements. Finally, the initialized MOEA / D algorithm population, weight vector set, neighborhood set, and global reference point are output.

[0158] For example, this step can be implemented using the following pseudocode: import numpy as np def init_moead(decision_space, hard_constraints, objective_functions,N=100, m=3, T=20): # 1. Generate a uniformly distributed weight vector def generate_uniform_weights(N, m): weights = [] step = 1.0 / (N - 1) for i in range(N): lambda1 = i * step for j in range(N - i): lambda2 = j * step lambda3 = 1.0 - lambda1 - lambda2 if lambda3>= 0: weights.append([lambda1, lambda2, lambda3]) # Sample N uniform weights weights = np.array(weights) np.random.shuffle(weights) return weights[:N, :] weights = generate_uniform_weights(N, m) # 2. Constructing a neighborhood set neighborhood = [] for i in range(N): dist = np.linalg.norm(weights - weights[i], axis=1) nearest_idx = np.argsort(dist)[:T] neighborhood.append(nearest_idx) # 3. Initialize the population population = [] fitness = [] while len(population) <N: x = generate_random_individual(decision_space) if hard_constraints(x): population.append(x) fitness.append(objective_functions(x)) population = np.array(population) fitness = np.array(fitness) # 4. Initialize the global reference point z_ref = np.min(fitness, axis=0) return population, weights, neighborhood, z_ref, fitness Step S4.3: Perform neighborhood update and crossover mutation operations on the MOEA / D multi-objective optimization algorithm population and weight vector set to obtain a new generation of optimization population individual set.

[0159] Preferably, the neighborhood iteration update rule follows the MOEA / D standard neighborhood search framework. For each individual i (i=1,2,...,N) in the population, two distinct parent individuals p and q are randomly selected from its neighborhood set B(i) as parent samples for crossover mutation, ensuring that the search range is concentrated within the neighborhood and improving convergence efficiency.

[0160] Preferably, the differential evolution crossover and mutation operation adopts the industry-standard DE / rand / 1 differential evolution strategy to generate candidate individuals y, and the calculation formula is as follows: . Where F=0.5 is the mutation scaling factor, CR=0.9 is the crossover probability, and j randThe dimension index of the randomly selected decision variables is used to ensure that at least one dimension of the candidate individual is mutated; for discrete decision variables x1, x3, and x4, the nearest valid integer value is taken after cross-mutation to ensure that the variable type and value range are compliant.

[0161] Preferably, hard constraint checks can be performed on the generated candidate individuals y. If the constraints are not met, targeted repair is performed: x2≥T s The correction is x2=T s -1s; If the online execution mode conflicts with the flashback database level, correct x1 to the flashback table level; If the variable exceeds the upper and lower bounds, truncate it to the legal value range, and after the repair, ensure that the individual 100% meets all hard constraints.

[0162] Preferably, for the generation of the new generation population, neighborhood crossover mutation and constraint repair can be performed on all N individuals to generate N legal candidate individuals, forming a set of individuals for the new generation optimized population. The objective function value F(y) of each new individual is calculated simultaneously to provide input for subsequent fitness calculation.

[0163] For example, this step can be implemented using the following pseudocode: def generate_new_generation(population, neighborhood, hard_constraints, T_s, CR=0.9, F=0.5): N, D = population.shape new_population = population.copy() for i in range(N): # Select 2 parent individuals from the neighborhood p, q = np.random.choice(neighborhood[i], 2, replace=False) parent_p = population[p] parent_q = population[q] # Differential Evolution Crossover Mutation j_rand = np.random.randint(0, D) y = new_population[i].copy() for j in range(D): if np.random.rand() <CR or j == j_rand: y[j] = parent_p[j]+ F * (parent_q[j] - parent_p[j]) # Integering of discrete variables y[[0,2,3]] = np.round(y[[0,2,3]]).astype(int) # Constraint Repair y = repair_constraints(y, hard_constraints, T_s) new_population[i] = y return new_population Step S4.4 involves calculating the fitness of the Chebyshev aggregation function for the set of individuals in the new generation of optimized population, as well as screening and sorting non-dominated solutions to obtain the Pareto optimal solution set.

[0164] Preferably, for updating the global reference point, the global reference point z* can be updated based on the objective function values ​​of all individuals in the new generation population. The update formula for each objective dimension is as follows: z j *=min(z j *,min{F(y i The function )j|i=1,2,...,N} ensures that the reference point is always the optimal target value for all individuals, thus meeting the computational requirements of the Chebyshev aggregation function.

[0165] Preferably, the fitness calculation of the Chebyshev aggregation function can be performed using the MOEA / D standard Chebyshev aggregation function to calculate the individual fitness, decomposing the multi-objective optimization problem into single-objective sub-problems. The fitness calculation formula for a single individual is as follows: g te (x i |λ i ,z*)=max 1≤j≤m {λ ji ×|f j (x i )-z j *|}. Where m=3 is the objective number, λ i Z represents the weight vector corresponding to an individual, and z* is the global reference point. The smaller the fitness value, the better the overall optimization effect of the individual, which meets the requirement of minimizing the optimization objective.

[0166] Preferably, for neighborhood individual replacement, each newly generated candidate individual y can be replaced. iCalculate the fitness value of the candidate individual under all weight vectors in the neighborhood B(i). If the fitness value of the candidate individual is less than the fitness value of the corresponding individual in the neighborhood, replace the original neighborhood individual with the candidate individual to complete the iterative update of the population and ensure that the population converges to the Pareto optimal frontier.

[0167] Preferably, after the population update is completed, the Pareto non-dominated sorting method is used to perform stratified screening on all individuals in the current population: for solution x, if there is no other solution y such that y is not inferior to x in all three objectives and is superior to x in at least one objective, then x is determined to be a non-dominated solution; all non-dominated solutions form the first non-dominated layer, which is the final Pareto optimal solution set.

[0168] Preferably, if the current iteration number reaches the maximum iteration number G max If the value is 200, or the Pareto optimal solution set has not been updated for 20 consecutive generations, then the iteration terminates and the final Pareto optimal solution set is output; otherwise, return to step S4.3 to continue iterative optimization.

[0169] For example, this step can be implemented using the following pseudocode: def update_population_and_get_pareto(new_population, weights,neighborhood, z_ref, objective_functions, fitness): N = new_population.shape[0] new_fitness = np.array([objective_functions(x) for x in new_population]) # Update global reference point z_ref = np.min(np.vstack([z_ref, new_fitness]), axis=0) # Neighborhood Individual Replacement for i in range(N): for k in neighborhood[i]: # Calculate Chebyshev fitness g_new = np.max(weights[k] * np.abs(new_fitness[i]- z_ref)) g_old = np.max(weights[k] * np.abs(fitness[k]- z_ref)) if g_new <g_old: fitness[k] = new_fitness[i] new_population[k] = new_population[i] # Pareto nondominated solution screening def is_non_dominated(x, fit_matrix): for fit in fit_matrix: if np.all(fit<= x) and np.any(fit <x): return False return True pareto_mask = np.array([is_non_dominated(f, fitness) for f fitness]) pareto_solutions = new_population[pareto_mask] pareto_fitness = fitness[pareto_mask] return pareto_solutions, pareto_fitness, new_population, fitness,z_ref Step S4.5: Match and map the Pareto optimal solution set with the Oracle Flashback recovery level and execution rule base to generate a set of candidate Flashback execution schemes.

[0170] Preferably, the construction of Oracle flashback recovery levels and execution rule bases is as follows: Based on Oracle's official technical specifications, a fixed flashback execution rule base is built. Each recovery level corresponds to a unique precondition, execution instruction template, verification rule, and resource requirement. Commonly used core mapping relationships are shown in Table 1 below: Table 1: Core Mapping Relationship Table.

[0171] Preferably, for the matching mapping between Pareto solutions and the rule base, for each individual xi in the Pareto optimal solution set, the recovery level, target time node, recovery data range, and execution mode corresponding to its decision variables can be extracted, and accurately matched with the execution rules of the corresponding recovery level in the rule base. The dynamic parameters in the execution instruction template are then filled to generate a complete candidate flashback execution plan. Each plan includes: a unique plan ID, a full name of the recovery level, a target timestamp, details of the recovery data range, an execution mode, a list of pre-verification items, a standardized execution step sequence, a resource requirement list, an estimated execution duration, and an estimated business impact.

[0172] Preferably, for each generated candidate solution, a pre-condition pre-verification is performed. Through the database read channel established in step S1, it is checked whether the current Oracle database meets all the mandatory preconditions of the corresponding recovery level. Invalid solutions that do not meet the technical requirements are eliminated, and the remaining valid solutions form a candidate flashback execution solution set. Each solution corresponds to a Pareto optimal solution to ensure technical feasibility and business adaptability.

[0173] For example, this step can be implemented using the following pseudocode: def generate_candidate_schemes(pareto_solutions, oracle_flashback_rulebase, db_conn): candidate_schemes = [] for idx, x in enumerate(pareto_solutions): # Extract decision variables level_code = int(x[0]) target_time = x[1] restore_range = int(x[2]) exec_mode = int(x[3]) # Matching rule library level_rule = oracle_flashback_rulebase[level_code] # Precondition pre-validation pre_check_result = pre_check_flashback_condition(db_conn, level_rule["preconditions"], target_time) if not pre_check_result: continue # Fill in the execution template to generate the complete solution scheme = { "scheme_id": f"FLASHBACK_SCHEME_{idx+1}", "flashback_level": level_rule["level_name"], "target_timestamp": target_time, "restore_range": get_restore_range_detail(restore_range), "exec_mode":"online"if exec_mode ==1 else"offline", "pre_check_items": level_rule["preconditions"], "exec_steps": fill_exec_template(level_rule["exec_template"],target_time, restore_range), "estimated_duration": calc_estimated_duration(x), "business_impact": calc_business_impact(x) } candidate_schemes.append(scheme) return candidate_schemes Step S4.6: Perform global optimal solution filtering on the candidate flashback execution scheme set to obtain the target flashback execution scheme.

[0174] Preferably, the multi-attribute decision screening method uses TOPSIS (Topology of Ideal Solutions) to complete the final screening of Pareto solutions. This method is a standard multi-attribute decision algorithm that can quantitatively evaluate the closeness of each candidate solution to the ideal solution and screen out the solution with the best overall performance, thus adapting to the multi-dimensional needs of automated storage and retrieval system business scenarios.

[0175] Preferably, the core screening process of TOPSIS is as follows: (1) Constructing the decision matrix: Let the total number of candidate solutions be K, and the decision attributes be 3 optimization objectives (all cost-type indicators, the smaller the better), construct a K×3 dimensional decision matrix D=[d ij ] K×3 , where d ij Let be the j-th objective function value of the i-th scheme.

[0176] (2) The normalization formula for the decision matrix vector normalization is: Generate a standardized decision matrix R=[r ij ] K×3 .

[0177] Preferably, for constructing the weighted normalization matrix, fixed weights can be assigned to the three objectives based on the operational priorities of the automated storage and retrieval system: recovery accuracy weight w1 = 0.4 (highest priority), recovery efficiency weight w2 = 0.35, and operational impact weight w3 = 0.25, with a sum of weights of 1; the weighted normalization matrix V = [v ij ] K×3 , where v ij =w j ×r ij .

[0178] Preferably, the ideal solution S + S represents the optimal value for each attribute (minimum value for cost-related indicators). + =(min(v i1 ),min(v i2 ),min(v i3 Negative ideal solution S - S represents the worst value of each attribute (the maximum value is taken for cost-related indicators). - =(max(v i1 ),max(v i2 ),max(v i3 )).

[0179] Preferably, for calculating the Euclidean distance, the distance from each solution to the positive ideal solution is... Distance to the negative ideal solution The calculation formula is: , .

[0180] Preferably, for calculating the closeness, the comprehensive closeness of each scheme is... C i The value range is [0,1], C i The larger the value, the better the overall performance of the solution.

[0181] Preferably, all candidate solutions can be sorted by proximity C. i Sort in descending order, select C.i The largest possible solution serves as the final target flashback execution solution, and the complete execution steps, pre-verification rules, and parameter configuration details of the solution are output synchronously to ensure that it can be directly used for the flashback operation execution in step S5.

[0182] For example, this step can be implemented using the following pseudocode: def select_optimal_scheme(candidate_schemes, weights=[0.4, 0.35,0.25]): # Constructing a decision matrix K = len(candidate_schemes) D = np.zeros((K, 3)) for i, scheme in enumerate(candidate_schemes): D[i, 0] = scheme["f1"] D[i, 1] = scheme["f2"] D[i, 2] = scheme["f3"] # Vector normalization R = D / np.linalg.norm(D, axis=0) # Weighted Standardization Matrix V = R * np.array(weights) # Determine the positive and negative ideal solutions S_plus = np.min(V, axis=0) S_minus = np.max(V, axis=0) # Calculate Euclidean distance D_plus = np.linalg.norm(V - S_plus, axis=1) D_minus = np.linalg.norm(V - S_minus, axis=1) # Calculate proximity C = D_minus / (D_plus + D_minus) # Filtering the optimal solution optimal_idx = np.argmax(C) optimal_scheme = candidate_schemes[optimal_idx] return optimal_scheme Beneficial effects of steps S4.1 to S4.6: This series of steps relies on multi-objective optimization algorithms to automate the generation and optimization of flashback recovery solutions. It addresses the issues of insufficient adaptability of recovery strategies and strong subjectivity in manual solution formulation in existing technologies. It balances multiple dimensions of needs such as recovery efficiency, recovery accuracy, and impact on system operation, matches appropriate flashback execution strategies for different abnormal scenarios, reduces manual intervention in the solution formulation process, provides clear and reasonable execution basis for subsequent flashback operations, and adapts to the diverse data anomaly recovery needs of automated three-dimensional warehouse systems.

[0183] The process involves the following steps: Step S4.1 establishes a computational framework adapted to the optimization algorithm, clarifying the decision boundaries and objectives for subsequent optimization calculations; Step S4.2 initializes the algorithm population and assigns weights to ensure the coverage and computational stability of the optimization process; Step S4.3 iteratively updates the population, expanding the search range of the solution space and improving the efficiency of obtaining high-quality solutions; Step S4.4 calculates fitness and filters non-dominated solutions to obtain the optimal solution set that meets multi-dimensional requirements; Step S4.5 matches and maps the optimal solution set with the flashback rule base, generating multiple sets of compliant candidate recovery schemes; and Step S4.6 filters the globally optimal scheme and outputs a flashback execution scheme adapted to the current abnormal scenario.

[0184] Step S5: Perform the corresponding level of flashback operation according to the target flashback execution plan to generate the full dataset of the business database after flashback.

[0185] Preferably, this step is the core execution and implementation stage of the data flashback method. It strictly follows the target flashback execution plan output by S4.6, adheres to the official flashback technical specifications of Oracle database, and completes the entire process of execution environment adaptation, standardized instruction generation, kernel-level flashback operation execution, and data recovery integration. The final output is a full dataset of the business database after flashback, which is in a unified format and can be directly used for verification.

[0186] Furthermore, step S5 specifically includes the following steps: Step S5.1: Obtain the target flashback execution plan and extract the flashback recovery level, target time node, scope of operation object, and execution timing rules within the plan.

[0187] Preferably, the target flashback execution plan output in step S4.6 of the data source acceptance and locking process is used as the sole input source, prohibiting the introduction of other external plans or manual modification of parameters. The plan file contains complete decision variable configuration, Oracle flashback execution rules, pre-verification checklist, business adaptation parameters, and execution plan integrity verification. Verification items include the uniqueness of the plan ID, compliance of the recovery level, validity of the target timestamp, and traceability of the operation object. If the verification fails, the plan re-screening process in step S4 is triggered.

[0188] Preferably, the process for targeted extraction and standardized transformation of core parameters is as follows: (1) Flashback recovery level extraction: Extract the recovery level code and official full name in the scheme, complete the one-to-one mapping verification between the code and Oracle's official flashback capability, ensure that the level code falls within the legal range of 0-5, and simultaneously extract the corresponding level's enforcement requirements and permission configuration.

[0189] (2) Target time node extraction: Extract the Unix millisecond-level target timestamp in the scheme, convert it into the TIMESTAMP (3) format natively supported by Oracle database, verify that the target timestamp is earlier than the start time of the abnormal event and is within the coverage of database undo_retention and flashback log, and control the time format conversion error within ±1ms.

[0190] (3) Extraction of the scope of operation objects: The recovery scope configuration in the decomposition scheme is refined into four levels: tablespace name, database user, business table details, and row-level data filtering conditions. A structured list of operation objects is generated. Each object in the list is bound to a unique object ID and data dictionary metadata to ensure that there are no omissions or out-of-scope operation objects.

[0191] (4) Extraction of execution timing rules: Deconstruct the execution mode and process requirements in the scheme, extract five core timing parameters: pre-verification window period, pre-execution timeout threshold, formal execution timing node, post-check interval, and number of retry attempts, generate a linear execution timing dependency link, and clarify the pre-completion conditions of each execution node.

[0192] Preferably, cross-consistency verification can be performed on the four types of core parameters extracted to ensure that the recovery level matches the execution mode, the target time node matches the change trajectory of the operation object, and the execution timing rules match the execution requirements of the recovery level. After the verification is passed, the parameters are encapsulated into a structured parameter set, which serves as the sole execution benchmark for subsequent steps.

[0193] For example, this step can be implemented using the following pseudocode: import cx_Oracle import datetime from datetime def extract_scheme_core_params(target_scheme): # Solution integrity verification required_fields = ["scheme_id","flashback_level_code","target_timestamp","restore_range_detail","exec_timing_rules"] for field in required_fields: if field not in target_scheme: raise ValueError(f"The scheme is missing a required field: {field}") # 1. Extract and verify the flashback recovery hierarchy flashback_level_code = int(target_scheme["flashback_level_code"]) flashback_level_name = target_scheme["flashback_level"] The statement `assert flashback_level_code in range(6)` indicates that the flashback level code is outside the valid range. # 2. Extract and transform the target time point target_unix_ts = target_scheme["target_timestamp"] target_oracle_ts = datetime.fromtimestamp(target_unix_ts / 1000).strftime("%Y-%m-%d %H:%M:%S.%f")[:-3] # 3. Extract the scope of the operation objects and generate a structured list. restore_range = target_scheme["restore_range_detail"] operation_object_list = build_object_list(restore_range) # 4. Extract execution timing rules exec_timing_rules = target_scheme["exec_timing_rules"] timing_param_set = extract_timing_params(exec_timing_rules) # Cross-consistency check cross_validation(flashback_level_code, target_oracle_ts, operation_object_list, timing_param_set) # Encapsulate the core parameter set core_param_set = { "flashback_level": (flashback_level_code, flashback_level_name), "target_timestamp": target_oracle_ts, "operation_objects": operation_object_list, "timing_params": timing_param_set } return core_param_set Step S5.2 involves pre-allocating and locking resources for the flashback recovery level, target time node, scope of operation objects, execution timing rules, and execution interface of Oracle database flashback technology to obtain the configuration parameters for the adapted flashback execution environment.

[0194] Preferably, the Oracle official execution interface can be connected using the Oracle OCI (Oracle Call Interface) standardized interface consistent with step S1 to establish a dedicated execution session, and simultaneously connect to the two official flashback execution interfaces of Oracle's built-in DBMS_FLASHBACK system package and FLASHBACK SQL execution engine. The execution session uses an independent dedicated connection throughout, without occupying the database connection pool resources of the business system, thus avoiding interference with normal business operations.

[0195] Preferably, a pre-configuration environment test can be performed first. Based on the extracted core parameters, a pre-verification of the flashback execution environment is performed. The verification items include: the database flashback function is enabled, the available capacity of the undo tablespace, the undo data coverage of the target timestamp, the recycle bin status (corresponding to the flashback deletion level), the database archiving mode, and the flashback operation permissions of the executing user. All verification items must have a pass rate of 100%. If any item does not meet the requirements, the environment pre-configuration correction will be automatically triggered.

[0196] Preferably, the resource pre-allocation and locking rules are as follows: (1) Memory resource pre-allocation: Allocate fixed PGA memory for dedicated execution sessions, with an allocation size of 2GB, to ensure the sorting and data reading performance of flashback operations; pre-occupy undo table space of no less than 30% of the total capacity to prevent undo data from being overwritten during flashback execution, which would lead to execution failure.

[0197] (2) Operation object locking: According to the scope of the operation object, a hierarchical locking mechanism is implemented: row-level shared locks are applied to the row-level recovery scope, table-level read-only locks are applied to the table-level recovery scope, and the database is switched to the mount state (business writes are prohibited) for the full database recovery scope. During the locking period, only flashback execution sessions are allowed to perform write operations. The locking duration is completely matched with the execution window period of the execution timing rules.

[0198] (3) Session parameter configuration: Based on the recovery level, configure dedicated session parameters, including undo_retention temporarily extended to twice the duration of the target timestamp, flashback_retention_target matching the execution duration, dml_locks temporarily expanded to twice the number of operation objects, setting the execution timeout threshold to 1.5 times the estimated execution duration, and fixing the number of retry attempts for failure to 3.

[0199] Preferably, after completing resource pre-allocation and locking, a standardized set of flashback execution environment configuration parameters is generated, including a dedicated session ID, a list of locked objects, session parameter key-value pairs, memory allocation configuration, interface call permission credentials, execution timeout and retry rules. All parameters are adapted one-to-one with the extracted core parameters, with no redundant configuration, serving as the sole environmental benchmark for subsequent instruction generation and execution.

[0200] For example, this step can be implemented using the following pseudocode: def build_flashback_exec_env(core_param_set, db_conn_pool): # Establish a dedicated execution session exec_conn = db_conn_pool.acquire() exec_conn.autocommit = False cursor = exec_conn.cursor() # Execution Environment Pre-verification env_check_result = flashback_env_precheck(cursor, core_param_set) if not env_check_result: raise EnvironmentError("Flashback execution environment pre-verification failed") # Resource pre-allocation and session parameter configuration pga_alloc_sql="ALTER SESSION SET PGA_AGGREGATE_LIMIT = 2G" undo_sql = f"ALTER SYSTEM SET UNDO_RETENTION = {int(core_param_set['timing_params']['max_exec_window']*2)} SCOPE=MEMORY" cursor.execute(pga_alloc_sql) cursor.execute(undo_sql) # Hierarchical locking of operation objects lock_sql_list = build_lock_sql(core_param_set["operation_objects"],core_param_set["flashback_level"][0]) for sql in lock_sql_list: cursor.execute(sql) # Generate execution environment configuration parameter set exec_env_config = { "exec_session_id": exec_conn.version, "db_cursor": cursor, "db_connection": exec_conn, "locked_objects": core_param_set["operation_objects"], "session_params": {"pga_limit":"2G","undo_retention": core_param_set['timing_params']['max_exec_window']*2}, "exec_timeout": core_param_set['timing_params']['exec_timeout'], "retry_times": core_param_set['timing_params']['retry_times'] } return exec_env_config Step S5.3 involves decomposing the execution timing of the flashback execution environment configuration parameters and mapping the instructions to generate a standardized flashback operation instruction sequence.

[0201] Preferably, the execution timing linear decomposition process is based on the execution timing rules, decomposing the complete flashback process into branchless, strongly dependent serial execution stages, fixed into 5 standard execution stages. Each stage is set with unique pre-dependent conditions and timeout thresholds. The stage order is: ① secondary verification stage of environment parameters → ② flashback execution pre-preparation stage → ③ pre-execution verification stage → ④ formal flashback operation execution stage → ⑤ preliminary verification stage of execution results. The execution duration and number of retries of each stage strictly match the flashback execution environment configuration parameters.

[0202] Preferably, the hierarchical instruction mapping rules can be based on the flashback recovery level, matching Oracle's official standard SQL / PLSQL syntax, breaking down each execution stage into directly executable standardized instructions, strictly adhering to the Oracle flashback technology syntax specifications, with different recovery levels corresponding to exclusive instruction templates: (1) Flashback query / version query / transaction query level: mapped to AS OFT IMESTAMP query statement, VERSIONS BETWEEN trajectory query statement, UNDO_SQL generation statement, data repair DML statement, and the instructions include row-level filtering conditions and transaction control statements.

[0203] (2) Flashback table level: mapped to ALTER TABLE...ENABLE ROW MOVEMENT row-level move enable statement, FLASHBACK TABLE...TO TIMESTAMP core flashback statement, constraint and index status verification statement.

[0204] (3) Flashback deletion level: mapped to FLASHBACK TABLE...TO BEFORE DROP recycle bin recovery statement, table structure and data consistency verification statement.

[0205] (4) Flashback database level: mapped to SHUTDOWN IMMEDIATE, STARTUP MOUNT state switching statement, FLASHBACK DATABASE TO TIMESTAMP core flashback statement, and ALTER DATABASE OPEN RESETLOGS database startup statement.

[0206] Preferably, all generated instructions can be standardized and encapsulated. Each instruction includes a unique instruction ID, the execution stage to which it belongs, the SQL / PLSQL text, the binding parameters, the execution timeout threshold, the failure retry rules, the exception handling logic, and the execution result verification rules. Hard-coded parameters are prohibited. All dynamic parameters are bound from the core parameter set and the execution environment configuration parameters to ensure that the instructions can be executed repeatedly and without syntax errors.

[0207] Preferably, all the encapsulated standardized instructions can be arranged in the order of the disassembled serial execution stages to generate a linear flashback operation instruction sequence. There is no parallelism or branching in the instructions within the sequence. The successful execution of the previous instruction is the only prerequisite for the execution of the next instruction. The execution flowchart and exception rollback plan of the instruction sequence are generated simultaneously to ensure that the execution process is controllable.

[0208] For example, this step can be implemented using the following pseudocode: def generate_flashback_instruction_sequence(core_param_set, exec_env_config): # The execution sequence is broken down into 5 standard phases exec_phases = [ "env_recheck","preparation","pre_exec_verify","formal_exec","result_check" ] # Load the official command template for the corresponding recovery level level_code = core_param_set["flashback_level"][0] instruction_template = load_oracle_flashback_template(level_code) instruction_sequence = [] instruction_id = 1 # Generate standardized instructions stage by stage for phase in exec_phases: phase_template = instruction_template[phase] phase_timeout = exec_env_config["exec_timeout"] / len(exec_phases) phase_retry = exec_env_config["retry_times"] # Fill template parameters and generate instructions for template_sql in phase_template: filled_sql = fill_sql_template(template_sql, core_param_set,exec_env_config) # Package standardized instructions standard_instruction = { "instruction_id": f"FLASHBACK_INST_{instruction_id}", "exec_phase": phase, "exec_sql": filled_sql, "bind_params": get_bind_params(core_param_set, phase), "timeout": phase_timeout, "retry_times": phase_retry, "exception_handler": get_exception_handler(level_code,phase), "result_check_rule": get_result_check_rule(level_code, phase) } instruction_sequence.append(standard_instruction) instruction_id += 1 # Instruction sequence syntax pre-validation for inst in instruction_sequence: syntax_check_result = oracle_sql_syntax_check(inst["exec_sql"],exec_env_config["db_cursor"]) if syntax_check_result: raise SyntaxError(f"Syntax validation failed for instruction {inst['instruction_id']}") return instruction_sequence Step S5.4: The standardized flashback operation instruction sequence is sent to the database execution kernel to perform the corresponding level of flashback operation, generating the database change log and temporary recovery dataset.

[0209] Preferably, the instruction delivery channel and execution rules can be established through the dedicated execution session and OCI interface in step S5.2 to sequentially deliver the standardized flashback operation instruction sequence to the Oracle database kernel for execution, strictly adhering to the serial execution rules: only after the current instruction is successfully executed and passes the result verification rules can the next instruction be delivered; if the instruction execution fails, the preset exception handling logic is triggered, and the instruction is re-executed within the number of retries; if the number of retries is exceeded, a full process rollback is triggered, the execution is terminated, and the exception is reported.

[0210] Preferably, during instruction execution, the execution status, execution time, number of affected rows, and kernel return code of each instruction are collected in real time. Simultaneously, all records related to the flashback operation in the Oracle database alarm log and online redo log are captured. When the deviation between the execution progress and the preset timing rules exceeds ±10%, a timeout warning is triggered to ensure that the entire execution process is controllable.

[0211] Preferably, the hierarchical execution mode is as follows: (1) Online hot standby execution mode: For non-full database recovery level, the database remains open during execution, and the business system can perform read-only operations normally. The recovery data generated by the flashback operation is first written to a dedicated temporary table in the Oracle temporary tablespace, without directly modifying the business production table, thus avoiding irreversible modification to the business data. The structure of the temporary table is completely consistent with the corresponding business table.

[0212] (2) Offline shutdown execution mode: For the flashback database level, the database is switched to the mount state in strict accordance with the timing rules. After the execution is completed, it is switched back to the open state. Business systems are prohibited from accessing the database during the execution process. The flashback operation directly completes the full database data recovery in the database kernel and generates a full execution log synchronously.

[0213] Preferably, after execution, the Redo Log, Undo Log, transaction execution log, and kernel execution record of the entire flashback operation are extracted, sorted according to execution time sequence, and a structured database change log is generated. Each log entry is bound to a corresponding instruction ID, transaction ID, execution timestamp, and affected data range. In online execution mode, all recovered data in the temporary tablespace is integrated according to the business table structure to generate a temporary recovery dataset containing table structure metadata, row-level data, index definitions, and constraint rules. In offline execution mode, the full data image after the database kernel recovery is extracted to generate a structured temporary recovery dataset. This dataset is not directly written to the business production database but is only used for subsequent integration and verification.

[0214] For example, this step can be implemented using the following pseudocode: def execute_flashback_instruction_sequence(instruction_sequence,exec_env_config): cursor = exec_env_config["db_cursor"] exec_conn = exec_env_config["db_connection"] db_change_log = [] # Execute instruction sequence one by one for inst in instruction_sequence: retry_count = 0 exec_success = False while retry_count <inst["retry_times"] and not exec_success: try: # Commands are sent to the database kernel for execution cursor.execute(inst["exec_sql"], inst["bind_params"]) # Execution result verification check_result = exec_result_check(cursor, inst["result_check_rule"]) if not check_result: raise Exception(f"Instruction {inst['instruction_id']} failed validation") # Record execution logs exec_record = { "instruction_id": inst["instruction_id"], "exec_phase": inst["exec_phase"], "exec_timestamp": datetime.now().timestamp()*1000, "exec_duration": cursor.stats["elapsed_time"], "affected_rows": cursor.rowcount, "return_code": 0 } db_change_log.append(exec_record) exec_success = True except Exception as e: retry_count += 1 exec_record = { "instruction_id": inst["instruction_id"], "retry_count": retry_count, "error_msg": str(e), "return_code": -1 } db_change_log.append(exec_record) if retry_count>= inst["retry_times"]: exec_conn.rollback() raise RuntimeError(f"Instruction {inst['instruction_id']} failed to execute, exceeding the retry limit") # Transaction commit (only pre-execute and verify instructions; actual modification instructions are committed after data verification is successful) exec_conn.commit() # Generate temporary recovery dataset temp_restore_dataset = build_temp_restore_dataset(cursor, exec_env_config["locked_objects"]) return db_change_log, temp_restore_dataset Step S5.5: Perform full data integration and format synchronization on the database change log and temporary recovery dataset to generate the full dataset of the business database after flashback.

[0215] Preferably, the full data integration rules take the temporary recovery dataset as the core and associate it with the execution records of the database change log to complete multi-dimensional data integration: First, the transaction execution records and data modification trajectories in the change log are associated and bound with the corresponding tables and row data in the temporary recovery dataset to ensure that each piece of restored data can be traced back to the corresponding execution instructions and transactions; Second, the missing metadata information in the temporary recovery dataset is supplemented, including tablespace definitions, user permissions, index structures, primary and foreign key constraints, and trigger configurations, to ensure that the dataset contains full object information of the business database; Third, temporary data, test data, and redundant log data during the execution process are removed, and only production data and metadata related to the business system are retained.

[0216] Preferably, the format and benchmark synchronization process can use the structure, format, and encoding of the original business database collected in step S1 as the sole benchmark to perform a full format synchronization operation: First, the character set encoding is unified to AL32UTF8, which is completely consistent with the original business database; second, the table structure, field type, field length, and precision are unified to match the original business database, with no missing fields or type changes; third, the data timestamp format is unified to the native Oracle TIMESTAMP format, which is consistent with the time precision of the original data; fourth, the data sorting rules are unified, arranged in ascending order according to the primary key of the business table, which is completely consistent with the data organization form of the original database.

[0217] Preferably, the integrated data can undergo dual integrity checks. First, the number of tables, table structure, and number of fields in the dataset are checked to ensure that they match the original business database by 100%. Second, the number of data row records is checked to ensure that the deviation between the number of data row records and the number of records in the business database at the target time point does not exceed 0.01%, and that there are no null primary keys, no duplicate records, and no data with constraint conflicts. If the check fails, the re-integration process is triggered.

[0218] Preferably, after verification, the integrated full data and metadata are encapsulated according to the hierarchical structure of the business database's tablespaces, users, and tables to generate a standardized full dataset of the business database after flashback. The dataset contains full business table data of the business system, data dictionary metadata, constraint and index configurations, and full-link change logs of the flashback execution. The format is fully compatible with Oracle database import specifications and S6 data verification requirements, and can be directly used for subsequent verification and formal writing.

[0219] For example, this step can be implemented using the following pseudocode: def build_flashback_full_dataset(db_change_log, temp_restore_dataset,original_db_meta): # 1. Full Data Integration: Linking Change Logs and Recovery Data integrated_data = integrate_log_and_data(temp_restore_dataset, db_change_log) # 2. Complete metadata information full_meta_data = build_full_meta_data(original_db_meta, integrated_data["table_list"]) integrated_data["meta_data"] = full_meta_data # 3. Format synchronized with the original baseline format_synced_data = format_sync_with_original(integrated_data,original_db_meta) # 4. Integrity Verification integrity_check_result = full_dataset_integrity_check(format_synced_data, original_db_meta) if not integrity_check_result: raise ValueError("Database integrity check failed after flashback") # 5. Generate a standardized full dataset flashback_full_dataset = { "dataset_version":"1.0", "target_timestamp": format_synced_data["target_timestamp"], "flashback_level": format_synced_data["flashback_level"], "meta_data": format_synced_data["meta_data"], "business_table_data": format_synced_data["table_data"], "flashback_change_log": db_change_log, "format_standard":"Oracle 11g+ Full Dataset Specification" } return flashback_full_dataset Beneficial effects of steps S5.1 to S5.5: This series of steps completes the implementation of the flashback execution solution, establishes a standardized automated flashback operation execution chain, solves the problems of cumbersome traditional data recovery operation processes, excessive manual intervention, and insufficient execution stability, ensures the compatibility of flashback operation with the database operating environment, reduces the impact of recovery operation on normal system operation, achieves accurate recovery execution of target data, provides a standardized and unified dataset for subsequent data verification, and adapts to the continuous operation requirements of automated storage and retrieval systems.

[0220] The process includes the following steps: Step S5.1 extracts the core execution parameters from the execution plan to provide a clear execution benchmark for subsequent full-process operations; Step S5.2 completes the adaptation verification and resource pre-allocation of the execution environment to ensure the compliant and stable execution of the flashback operation; Step S5.3 completes the decomposition of the execution sequence and instruction mapping to generate a standardized execution instruction sequence; Step S5.4 completes the kernel execution of the flashback operation to realize the recovery processing of the target data; and Step S5.5 completes the full integration and format synchronization of the recovered data to output a standardized full dataset of the business database after the flashback.

[0221] Step S6: Perform data verification on the full dataset of the business database after the flashback. If the verification is successful, the full dataset of the restored database is obtained.

[0222] Preferably, this step is an industrial-grade closed-loop link in the data flashback process, focusing on the adaptability, risk controllability, and business linkage of the core business scenarios of automated warehouses in the tobacco industry, and completing full-dimensional verification and final implementation.

[0223] Furthermore, step S6 specifically includes the following steps: Step S6.1: Obtain the full dataset of the business database after the flashback and extract the business table structure metadata, data row record set, and time-series change trajectory information corresponding to the dataset.

[0224] Preferably, the dataset source for industrial scenario adaptation is the dataset output in step S5 or step S5.5 that is adapted to the business database specification of the automated storage and retrieval system in the tobacco industry of Oracle 11g and above. Priority is given to verifying whether the dataset contains complete data and metadata of the four core business tables: the location status table, the raw tobacco inventory master table, the finished tobacco inbound and outbound document table, and the aisle stacker crane task table.

[0225] Preferably, before formal extraction, the metadata index area of ​​the dataset can be scanned to confirm that the index area is not damaged or missing, and that the association mapping between the index area and the data body area is not broken. If an anomaly is found, the dataset re-integration process in step S5 is triggered directly, without proceeding to the subsequent verification stage.

[0226] Preferably, the corresponding information of the four core business tables can be extracted first, and then the information of other auxiliary business tables can be extracted to ensure that core business verification resources are allocated preferentially; the extracted time-series change trajectory information needs to be bound to business identifiers unique to the tobacco industry, such as raw tobacco batch number, finished cigarette carton code, cargo location code, and equipment number, to facilitate subsequent business link verification.

[0227] Step S6.2 involves performing a full-scale matching verification of field definitions, primary key constraints, and index rules for the business table structure metadata, data row record set, and time-series change trajectory information.

[0228] Preferably, for the location status table, the key verification is to check the length, format (the tobacco industry usually uses a fixed 12-digit format of "warehouse number-lane number-layer number-column number-location number"), and non-null identifier of the location code field; for the raw tobacco inventory master table, the key verification is to check the type, precision, and pre-structure definition of related foreign key constraints of the raw tobacco batch number, grade, weight, and moisture fields.

[0229] Preferably, structural differences can be divided into three levels: fatal differences, severe differences, and general differences. Fatal differences (such as missing core business tables or missing primary key fields) directly trigger the dataset re-integration process in step S5. Severe differences (such as incorrect field types or index types in core business tables) trigger the scheme re-selection process in step S4. General differences (such as adjustments to default values ​​in auxiliary business tables) are recorded and do not affect subsequent verification, but must be explained in the final recovery report.

[0230] Preferably, the extracted business table structure metadata can be compared in real time with the standard structure definition in the data dictionary management system that accompanies the automated storage and retrieval system, avoiding deviations in the manually maintained standard structure definition and ensuring the authority of the verification results.

[0231] Step S6.3 involves a full check of the number of records, non-null field values, and related foreign key constraints of the entire business database dataset, business table structure metadata, data row record set, and time-series change trajectory information after the table structure verification has passed the flashback.

[0232] Preferably, for the location status table, the key verification is whether the number of records for all locations in the warehouse is consistent with the total number of physical locations in the warehouse; for the raw tobacco inventory master table, the key verification is the uniqueness of the raw tobacco batch number, the non-empty identifier of the weight field, and the compliance of the enumerated values ​​of the grade field; for the finished tobacco inbound and outbound document table, the key verification is the continuity of the inbound and outbound document numbers and the uniqueness of the piece code field.

[0233] Preferably, integrity anomalies can be divided into three levels: fatal anomalies, severe anomalies, and general anomalies. Fatal anomalies (such as more than 1% missing records in the core business table or duplicate batch numbers of raw cigarettes) directly trigger the dataset re-integration process in step S5. Severe anomalies (such as more than 0.1% missing non-null fields in the core business table or more than 0.05% of invalid foreign key records) trigger the scheme re-screening process in step S4. General anomalies (such as missing non-null fields in the auxiliary business table) are recorded and do not affect subsequent verification, but need to be explained in the final recovery report.

[0234] Preferably, the number of records extracted from the core business table, the values ​​of non-null fields, and the related foreign key constraints can be compared in real time with the historical data snapshots generated by the WMS system at the flashback target time node to ensure the business rationality of the verification results.

[0235] Step S6.4: Perform a full verification of the data change sequence, business operation link, and time node matching degree of the full dataset of the business database, business table structure metadata, data row record set, and time sequence change trajectory information after the integrity verification passes.

[0236] Preferably, for the raw tobacco warehousing business chain, the focus is on verifying whether the sequence of "raw tobacco arrival registration → raw tobacco quality inspection → raw tobacco warehousing scheduling → raw tobacco storage location allocation → raw tobacco warehousing confirmation → raw tobacco inventory update" is correct; for the finished tobacco outbound business chain, the focus is on verifying whether the sequence of "finished tobacco order receipt → finished tobacco outbound scheduling → finished tobacco storage location allocation → finished tobacco outbound confirmation → finished tobacco inventory update" is correct.

[0237] Preferably, timing anomalies can be classified into three levels: fatal anomalies, severe anomalies, and general anomalies. Fatal anomalies (such as reverse order of core business links or time nodes exceeding the flashback target time node by ±1 hour) directly trigger the S5 dataset re-integration process. Severe anomalies (such as timing deviation of core business links exceeding ±10 seconds or time nodes exceeding the flashback target time node by ±10 minutes) trigger the S4 solution re-selection process. General anomalies (such as timing deviation of auxiliary business links exceeding ±1 minute) are recorded and do not affect subsequent verification, but must be explained in the final recovery report.

[0238] Preferably, the extracted time-series change trajectory information can be compared in real time with the historical operation logs generated by the WCS system before and after the flashback target time node to ensure the rationality of the equipment operation in the verification results.

[0239] Step S6.5: Perform a compliance summary judgment on the full dataset of the flashback business database, business table structure metadata, data row record set, and time-series change trajectory information that have passed the time-series consistency verification, and obtain the full dataset of the flashback business database that has passed the verification.

[0240] Preferably, the criteria for judging the summary of industrial-grade compliance can be a "one-vote veto system". All fatal and serious anomalies must be eliminated, and the number of general anomalies must not exceed 0.5% of the total verification items in order to be judged as passing the verification. If there are any fatal or serious anomalies that have not been eliminated, or if the number of general anomalies exceeds 0.5% of the total verification items, the subsequent process will be terminated directly, the anomaly list will be returned, and the review mechanism of the previous steps will be triggered.

[0241] Preferably, after the verification is passed, a structured industrial-grade recovery report can be generated simultaneously. The report includes the source of the dataset, the verification time, the verification personnel, the list of verification items, the verification results, the list of abnormal items, the list of general abnormal items, the risk assessment, and the follow-up recommendations, which facilitates subsequent auditing and traceability.

[0242] Preferably, the generated industrial-grade recovery report can be uploaded to the enterprise data governance platform in real time to complete the compliance filing of the data recovery process.

[0243] Step S6.6: Perform database writing and status synchronization operations on the full dataset of the business database after the flashback that has passed the verification, and obtain the full dataset of the restored database.

[0244] Preferably, the industrial-grade, risk-controllable database write mechanism can adopt a "dual transaction + dual backup" write mechanism; the first transaction is a pre-write transaction, which writes data to a temporary production database to verify the business availability of the temporary production database; the second transaction is a formal write transaction, which writes data to the formal production database; before the pre-write transaction, a full hot backup of the formal production database is performed; before the formal write transaction, a full hot backup of the temporary production database is performed; if any transaction fails, it is automatically rolled back to the state before execution and restored using the corresponding hot backup.

[0245] Preferably, after the formal write transaction is completed, the WMS, WCS, data dictionary management system, and enterprise data governance platform are notified in real time to refresh the cache; the WMS system is notified to suspend the receipt of new business orders and resume them after the cache is refreshed; the WCS system is notified to suspend the scheduling of new device tasks and resume them after the cache is refreshed; ensuring that the state of the upper-layer business system and the underlying database are completely consistent.

[0246] Preferably, after the status synchronization is completed, the full data of the industrial-grade final restored database is generated synchronously. The data includes complete business data, metadata, verification report, recovery execution log, hot backup file path, etc., which facilitates subsequent auditing and traceability.

[0247] Beneficial effects of steps S6.1 to S6.6: This series of steps completes multi-dimensional compliance verification of the data after flashback, establishes a fully automated data verification system, and solves the problems of insufficient consistency verification and inability to guarantee data availability after traditional data recovery. It covers multiple core verification dimensions such as table structure, data integrity, and business time sequence, closes the entire data flashback process, ensures the adaptability of the recovered data to the business operation requirements of the automated warehouse system, reduces the impact of data anomalies on subsequent warehousing operations, and reduces the cost and error of manual verification.

[0248] The process involves the following steps: Step S6.1 extracts the core metadata and business information of the recovered dataset to provide a basic reference for the entire process verification; Step S6.2 completes the matching verification of the table structure to ensure the structural compliance of the recovered data; Step S6.3 completes the full verification of data rows to ensure the integrity of the recovered data; Step S6.4 completes the consistency verification of business time sequence to ensure the matching of data with business links; Step S6.5 completes the summary judgment of all verification items to clarify the compliance status of the data; and Step S6.6 completes the formal writing and status synchronization of the verified data, outputting the usable full data of the recovered database.

[0249] In summary, the overall beneficial effects of steps S1 to S6 in this embodiment are as follows: This method is adapted to the continuous operation requirements of automated storage and retrieval systems (AS / RS), constructing an automated data anomaly identification and recovery process. It overcomes the shortcomings of traditional data recovery methods, such as cumbersome processes, significant downtime impact, and insufficient adaptability. It can adapt to data anomaly scenarios of varying degrees, reduce the impact of data recovery on normal system operation, improve the data security and operational stability of AS / RS, reduce manual intervention in the data recovery process, optimize the accuracy and efficiency of data recovery, and provide support for the stable operation of the system's core business.

[0250] Step S1 provides a unified basic data source for subsequent full-process data processing, ensuring the integrity and validity of the input data; Step S2 completes the standardization processing of multi-source data, eliminating differences in different data dimensions and providing suitable input data for subsequent anomaly detection; Step S3 completes the accurate location of data anomaly events, providing accurate basis for the formulation of recovery plans; Step S4 matches suitable flashback recovery strategies, ensuring the rationality and scenario adaptability of the recovery plan; Step S5 completes the flashback operation at the corresponding level, realizing the recovery execution of the target data; Step S6 completes the full-dimensional verification of the recovered data, ensuring the consistency and availability of the recovered data.

[0251] like Figure 2 As shown, this embodiment provides an example of a data flashback device for an automated storage and retrieval system. The giant data flashback device is applied to the data flashback method as described in the above embodiment.

[0252] Specifically, the data flashback device includes an automated storage and retrieval system data acquisition module 1, a multi-dimensional time-series standardized dataset acquisition module 2, an abnormal data change event location module 3, a target flashback execution plan acquisition module 4, a full data flashback module for the business database 5, and a business data verification module after flashback 6, which are connected electrically or through communication in sequence.

[0253] The automated storage and retrieval system (AS / RS) data acquisition module 1 collects the full operation logs, business operation time-series data, and data change trajectory sequences of the AS / RS database. The multivariate time-series standardized dataset acquisition module 2 performs time-series alignment and standardized encoding on the full operation logs, business operation time-series data, and data change trajectory sequences to generate a multivariate time-series standardized dataset. The abnormal data change event location module 3 inputs the multivariate time-series standardized dataset into the PatchTST time-series anomaly detection algorithm to locate abnormal data change events, obtaining an abnormal event time interval location result set. The target flashback execution plan acquisition module 4 inputs the abnormal event time interval location result set into the MOEA / D multi-objective optimization algorithm, matching the optimal recovery level and execution rules of Oracle flashback to obtain the target flashback execution plan. The business database full data flashback module 5 executes the corresponding level of flashback operation according to the target flashback execution plan, generating a full dataset of the business database after flashback. The flashback business data verification module 6 verifies the full dataset of the business database after flashback; if verification is successful, the full data of the recovered database is obtained.

[0254] Figure 3 This is a schematic diagram of the structure of an electronic device according to an embodiment of this application. Figure 3 As shown, the electronic device 7 includes a processor 71 and a memory 72 coupled to the processor 71.

[0255] The memory 72 stores program instructions for implementing the data flashback method of the automated storage and retrieval system of any of the above embodiments.

[0256] The processor 71 is used to execute program instructions stored in the memory 72 to perform data flashback for the automated storage and retrieval system.

[0257] The processor 71 can also be referred to as a CPU (Central Processing Unit). The processor 71 may be an integrated circuit chip with signal processing capabilities. The processor 71 can also be a general-purpose processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. A general-purpose processor can be a microprocessor or any conventional processor.

[0258] Furthermore, Figure 4 This is a schematic diagram of the structure of a storage medium according to an embodiment of this application. See also: Figure 4 The storage medium 8 in this embodiment stores program instructions 81 capable of implementing all the above methods. These program instructions 81 can be stored in the storage medium as a software product, including several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) or processor to execute all or part of the steps of the methods in each embodiment of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks, or terminal devices such as computers, servers, mobile phones, and tablets.

[0259] In the several embodiments provided in this application, it should be understood that the disclosed apparatus, devices, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another device, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between devices or units may be electrical, mechanical, signal, or other forms.

[0260] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated units described above can be implemented in hardware or as software functional units. The above are merely embodiments of this application and do not limit the patent scope of this application. Any equivalent structural or procedural transformations made based on the description and drawings of this application, or direct or indirect applications in other related technical fields, are similarly included within the patent protection scope of this application.

Claims

1. A data flash back method of an automated stereoscopic library system, characterized by, The data flashback method includes: Step S1: Collect the full operation logs, business operation time sequence data, and data change trajectory sequence of the automated storage and retrieval system database; Step S2: Perform time-series alignment and standardized encoding on the full operation log, the business operation time-series data, and the data change trajectory sequence to generate a multivariate time-series standardized dataset; Step S3: Input the multivariate time-series standardized dataset into the PatchTST time-series anomaly detection algorithm to locate abnormal data change events and obtain the result set of abnormal event time interval location. Step S4: Input the abnormal event time interval location result set into the MOEA / D multi-objective optimization algorithm, and obtain the target flashback execution plan by matching the optimal recovery level and execution rules of Oracle flashback; Step S5: Perform the corresponding level of flashback operation according to the target flashback execution plan to generate the full dataset of the business database after flashback; Step S6: Perform data verification on the full dataset of the business database after the flashback. If the verification is successful, the full dataset of the restored database is obtained.

2. The data flashback method of claim 1, wherein, Step S1: Collect the full operation logs, business operation time-series data, and data change trajectory sequences of the automated storage and retrieval system database, including: Step S1.1: Connect the standardized communication interface between the core database of the automated storage and retrieval system and the business execution system to establish a real-time channel for reading all data. Step S1.2: Continuously capture all running logs generated during database operation through the real-time full data reading channel; Step S1.3: Synchronously collect business operation time sequence data that matches the time axis of the full operation log through the full data real-time reading channel; Step S1.4: Capture the database data change trajectory sequence corresponding to the full operation log and the business operation time sequence data through the full data real-time reading channel; Step S1.5: Remove invalid null values ​​and duplicate data fragments from the full operation log, the business operation time sequence data, and the data change trajectory sequence; Step S1.6: Output the full running log, business operation time sequence data, and data change trajectory sequence that have been verified.

3. The data flashback method of claim 1, wherein, Step S2 involves performing time-series alignment and standardized encoding on the full operation logs, the business operation time-series data, and the data change trajectory sequence to generate a multivariate time-series standardized dataset, including: Step S2.1: Obtain the full operation log, the business operation time sequence data, and the data change trajectory sequence, and extract the set of native timestamp fields corresponding to each data dimension; Step S2.2: Perform time-series alignment on all data dimensions of the original timestamp field set based on a unified time granularity to obtain the time-series aligned full running log, business operation time-series data, and data change trajectory sequence. Step S2.3: Perform a mapping transformation from unstructured data to structured numerical data on the time-aligned full operation log, business operation time-series data, and data change trajectory sequence to obtain the structured encoded full operation log, business operation time-series data, and data change trajectory sequence. Step S2.4: Perform global numerical standardization on the structured encoded full operation log, business operation time series data, and data change trajectory sequence to obtain full operation log, business operation time series data, and data change trajectory sequence with unified dimensions; Step S2.5: The full-scale operation logs, business operation time-series data, and data change trajectory sequences with unified dimensions are spliced ​​and integrated along the same time axis to obtain a multi-dimensional time-series standardized dataset.

4. The data flashback method of claim 1, wherein, Step S3: Input the multivariate time-series standardized dataset into the PatchTST time-series anomaly detection algorithm to locate abnormal data change events, and obtain the result set of abnormal event time interval localization, including: Step S3.1: Obtain the multivariate time-series standardized dataset and extract the corresponding time axis index sequence and multidimensional feature sequence; Step S3.2: Input the time axis index sequence and the multi-dimensional feature sequence into the PatchTST time series anomaly detection algorithm, and generate a block-embedded feature sequence with position information through sequence block segmentation and position encoding operations; Step S3.3: Input the block-embedded feature sequence into the Transformer encoder layer of the PatchTST temporal anomaly detection algorithm to perform global temporal dependency modeling and calculation, and obtain the global temporal feature representation sequence; Step S3.4: Perform reverse reconstruction calculation of the time-series dimension on the global time-series feature representation sequence to obtain a reconstructed time-series dataset that matches the dimension of the multivariate time-series standardized dataset; Step S3.5: Perform point-by-point residual calculation on the reconstructed time series dataset and the multivariate time series normalized dataset to generate a time series residual sequence; Step S3.6: Perform adaptive anomaly threshold determination and continuous time interval aggregation on the time-series residual sequence to locate the boundary of abnormal data change events, and obtain the abnormal event time interval location result set.

5. The data flashback method of claim 1, wherein, Step S4: Input the abnormal event time interval location result set into the MOEA / D multi-objective optimization algorithm. By matching the optimal recovery level and execution rules of Oracle flashback, the target flashback execution plan is obtained, including: Step S4.1: Obtain the set of abnormal event time interval location results and construct the decision variable space, constraint set, and optimization objective function set adapted to the MOEA / D multi-objective optimization algorithm; Step S4.2: Input the decision variable space, the constraint set, and the optimization objective function set into the MOEA / D multi-objective optimization algorithm, and generate the initialized MOEA / D multi-objective optimization algorithm population and weight vector set through algorithm population initialization and uniform weight vector distribution operations; Step S4.3: Perform neighborhood update and crossover mutation operations on the MOEA / D multi-objective optimization algorithm population and the weight vector set to obtain a new generation optimization population individual set; Step S4.4: Perform fitness calculation for Chebyshev aggregation function adaptation on the set of individuals in the new generation of optimized population, and screen and sort non-dominated solutions to obtain the Pareto optimal solution set; Step S4.5: Match and map the Pareto optimal solution set with the Oracle flashback recovery level and execution rule base to generate a set of candidate flashback execution schemes; Step S4.6: Perform global optimal solution screening on the candidate flashback execution scheme set to obtain the target flashback execution scheme.

6. The data flashback method according to claim 1, characterized in that, Step S5: Execute the corresponding level of flashback operation according to the target flashback execution plan to generate a full dataset of the post-flashback business database, including: Step S5.1: Obtain the target flashback execution plan and extract the flashback recovery level, target time node, scope of operation object, and execution timing rules within the plan; Step S5.2: Pre-allocate and lock resources for the flashback recovery level, the target time node, the scope of the operation object, the execution timing rules, and the execution interface of Oracle database flashback technology to obtain the flashback execution environment configuration parameters that have been adapted. Step S5.3: Decompose the execution timing and map the instructions of the flashback execution environment configuration parameters to generate a standardized flashback operation instruction sequence; Step S5.4: The standardized flashback operation instruction sequence is sent to the database execution kernel to perform the corresponding level of flashback operation, generating a database change log and a temporary recovery dataset; Step S5.5: Perform full data integration and format synchronization on the database change log and temporary recovery dataset to generate a full dataset of the business database after flashback.

7. The data flashback method according to claim 1, characterized in that, Step S6: Perform data verification on the full dataset of the business database after the flashback. If the verification passes, the full dataset of the restored database is obtained, including: Step S6.1: Obtain the full dataset of the business database after the flashback and extract the business table structure metadata, data row record set, and time-series change trajectory information corresponding to the dataset; Step S6.2: Perform full matching verification of field definitions, primary key constraints, and index rules for the business table structure metadata, the data row record set, and the time-series change trajectory information; Step S6.3: Perform a full check on the full dataset of the business database after the table structure verification passes, including the business table structure metadata, data row record set, and time-series change trajectory information, to verify the number of records in the entire table, the values ​​of non-null fields, and the related foreign key constraints. Step S6.4: Perform a full verification of the data change sequence, business operation link, and time node matching degree of the full dataset of the business database, business table structure metadata, data row record set, and time sequence change trajectory information after the integrity verification passes. Step S6.5: Perform a compliance summary judgment on the full dataset of the business database after the flashback, the business table structure metadata, the data row record set, and the time-series change trajectory information that have passed the time-series consistency verification, and obtain the full dataset of the business database after the flashback that has passed the verification. Step S6.6: Perform database writing and status synchronization operations on the full dataset of the business database after the flashback that has passed the verification, and obtain the full dataset of the restored database.

8. A data flashback device for an automated storage and retrieval system, wherein the data flashback device is applied to the data flashback method as described in any one of claims 1 to 7, characterized in that, The data flashback device includes: The automated storage and retrieval system data acquisition module is used to collect the full operation logs, business operation time sequence data, and data change trajectory sequences of the automated storage and retrieval system database. The multivariate time-series standardized dataset acquisition module is used to perform time-series alignment and standardized encoding on the full operation log, the business operation time-series data, and the data change trajectory sequence to generate a multivariate time-series standardized dataset. The abnormal data change event localization module is used to input the multivariate time-series standardized dataset into the PatchTST time-series anomaly detection algorithm to locate abnormal data change events and obtain a set of abnormal event time interval localization results. The target flashback execution plan acquisition module is used to input the abnormal event time interval location result set into the MOEA / D multi-objective optimization algorithm, and obtain the target flashback execution plan by matching the optimal recovery level and execution rules of Oracle flashback; The business database full data flashback module is used to perform flashback operations at the corresponding level according to the target flashback execution plan and generate a full dataset of the business database after flashback. The Flashback Business Data Verification Module is used to verify the full dataset of the Flashback Business Database. Once the verification is successful, the full dataset of the restored database is obtained.

9. An electronic device, characterized in that, The method includes a processor and a memory coupled to the processor, the memory storing program instructions executable by the processor; when the processor executes the program instructions stored in the memory, it implements the data flashback method as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores program instructions that, when executed by a processor, enable the data flashback method as described in any one of claims 1 to 7.

Images