Database recovery

SQL Server query, MySQL table crash, Oracle data file damage, Kingdee UF account set cannot be opened--database damage does not mean that the data is gone. Most cases can be repaired to more than 90%, do not overwrite, do not rebuild first.

Common manifestations of database corruption are similar to the original Database Recovery Process Financial Software Set of Accounts real case price reference FAQ

Common manifestations and causes of database corruption

Database failure is different from file corruption, its symptoms are very "professional", and the corresponding causes are also different:

SQL Server database becomes Suspect: The most common. The transaction log (.ldf) is often half-written due to a power failure or disk space is full, which causes the log to fail to expand. The data file (.mdf) itself is often intact.
MySQL table flag crashed: MyISAM table index corruption after power failure, InnoDB may report page corruption. Forced restart cycle will aggravate the damage.
Oracle ORA-01578 Block corruption: The processing loss before the bad block spreads is the smallest.
Kingdee/UFIDA account set "account set is damaged and cannot be logged in": The bottom layer is the SQL Server database, and the financial software also overlays its own checklist. We have a special repair process for this type.
Ransomware encrypts database files:.mdf/.bak is encrypted. The peculiarities of database files are: large files tend to be encrypted only at the header (viruses for speed), table data areas may be intact, and repair is expected to be larger than ordinary files.

There are three common reasons:outage(More than half),Disk bad sectors, Mistake/Virus.

Database recovery process: every step prevents secondary corruption

shutdown protection site: The database service is stopped, and any program is prohibited from writing again. The most taboo is "repair while using".
total mirror: Make a read-only mirror of the disk where the data file is located, and then all repairs are done on the mirror copy-the original data will not be affected if the repair is damaged. This is the essential difference from the amateur practice of "direct modification".
damage assessmentParse database file header, page structure, system table, determine the scope of damage: is the log bad (easy to repair), or system table bad (medium), or data page damage in large areas (difficult to repair but still have a way).
layered repairLog reconstruction/truncation → system table repair → bad page skip extraction → bottom parsing directly extract table data. If you can go shallow, you don't go deep, and each layer is verified.
consistency verification: Completeness check (DBCC CHECKDB, etc.) should be run for the repaired library, and key business tables should be randomly checked: whether the number of rows, the total amount, and the most recent document can be opened.The database is not "mountable" even if the recovery is successful, the business data is not counted until it is matched.
Delivery and reinforcement recommendations: Delivery repaired library + damage cause analysis. UPS+ specification shutdown is recommended for power failure; disk replacement + backup plan is recommended for disk failure.

Financial Software Account Set: Kingdee/Yonyou's Special Experience

The financial software of small and medium-sized enterprises in Panyu is mainly Kingdee (KIS/K3) and UFIDA (T3/T6/U8). The damage of account set is our high-frequency business. Several key points are mentioned:

Repair the warehouse first, then repair the account: The bottom layer of account set is SQL Server. The first step is always to repair the database layer. After the database is repaired, the financial software will report errors, and then process the account set registration information and verification table of the software layer.
We are familiar with the structure of annual account set: Kingdee K3 AIS file, UF DATA library, T3 account set library, the table structure differences of each version are accumulated, when repairing, know which tables must be complete and which can be reconstructed from logs.
End of term data is most afraid of losing: Damage often occurs at month-end closing/year-end closing (heavy operation and large log). We will give priority to checking "voucher continuity" for damaged account sets during closing period-broken voucher number means that documents have not been repaired, which must be clearly informed, and delivery cannot be fooled.
After repair, we must make a backup system: Financial data cannot be lost. We deliver it with automatic backups (full daily + hourly transaction logs) at almost zero cost.

⚠️ Three taboos for database failure:Do not restart the database service repeatedly (each startup attempt may aggravate the damage); do not run around under the "one-click repair tool" on the Internet (write bad page table gods difficult to save); do not use DBCC CHECKDB REPAIR_ALLOW_DATA_LOSS direct repair (it will "repair" the way is to delete the data on the bad page). Stop the service first time, do mirroring, and then find us.

real case

This is how we help our clients solve problems.

Mold factory SQL Server query, power failure caused, 4 hours repair zero loss

In February 2026, a mold factory in Shilou tripped and lost power at night. In the morning, it was found that the SQL Server database of ERP became "doubtful" and the whole factory could not be opened. The first reaction of the electrician in the factory was to restart the server three times (fortunately, there was no random tool). We were present: stop service → do read-only mirroring of D disk.(1.2TB took 50 minutes) → Analysis found that only the tail of transaction log.ldf was damaged, and the data file.mdf was intact → Log reconstruction mode mount →DBCC CHECKDB full database verification passed → Business spot check: vouchers, inventory documents and customer orders of the current month were all complete. The whole process lasted for 4 hours, with zero data loss. After the event, they were equipped with UPS (online type 1KVA, RMB 1500) and daily automatic backup, and then tripped again in July of the same year. The server shut down smoothly, and nothing happened.

Yonyou T3 account set collapses during year-end closing, and all vouchers are recovered

At the peak of settlement at the end of January 2026, UF T3 of a trading company in Nansha crashed during the annual settlement process. After restarting, the account set login reported "database corruption". Annual settlement failed + account set damage, financial panic, which is the annual account. We analyzed after mirroring: a large number of writes encountered disk bad sectors during annual settlement (SMART hard drive shows that there are 512 remapped sectors, which should have been replaced long ago). Repair goes through two layers: first, the bottom tool skips the bad sector to extract the data page, and then reconstructs the system table; the attachment table page of 3 vouchers in the voucher table is damaged, and the body table is complete. Finally, more than 1800 vouchers in the whole year are restored, and the attachments of 3 vouchers (scanned invoice pictures) are lost. The financial department retrieves 2 from the mailbox transactions, and the actual loss is 1 attachment. After the repair, the hard drive was forcibly replaced and a backup was provided. The lesson of this case:SMART alarm hard drive, changing disk is always cheaper than repairing data.

price reference

Test first, quote later, repair later

Item	Reference Price	Notes
SQL Server Doubt Repair	RMB 800–3000	Evaluate the quote according to the degree of damage
MySQL/Table-level Repair	RMB 500–2000	Verification with index rebuild
Kingdee/Yonyou Account Set Repair	RMB 1500–5000	software layer check repair
Extortion encryption database rescue	by assessment	Analyze salvability before quoting.
Oracle Bad Block Repair	From RMB 2,000	RHYD-containing coordination
consistency check after repair	Included in Service	Lines/Amount/Doc Spot Check

* The above is the reference price, the specific price after inspection/survey shall prevail; batch/enterprise customers can negotiate discounts. Final pricing is subject to the actual on-site inspection.

FAQ

About database recovery, people often ask

What is the database recovery success rate?

Power failure/log damage class: more than 90% can be fully restored; disk bad sectors class: depending on the location of bad sectors, system table area damage is difficult, data area damage can skip extraction; ransomware encryption class: database large files often only encrypt the head, rescue most of the table data cases We have done a lot. All types we are first evaluated, reported success rate expectations, you confirm the start.

How long will it take to repair? Will it affect business?

Mild (doubt, log corruption) 4-8 hours on the same day; moderate 1-3 days. Database unavailable during repair, but if you have backup, you can restore to the backup point first (may lose the last few hours of data), repair the database good and then merge. Specific solution evaluation together.

How can we guarantee that the recovered data is correct?

Three-way verification: database level integrity check, key table rows and total business verification (such as total voucher number, total inventory amount), and recent document sample opening verification. Verification results are written into the delivery report, and the incorrect parts are listed truthfully--we do not deliver "open-looking" false libraries.

Can you do the backup plan by the way?

It is strongly recommended to do it together. The repair cost is several thousand RMB, and a set of automatic backup configuration is only a few hundred RMB (script + a backup hard drive). The database we repaired will be sent a backup scheme configuration by default, and then maintenance or single service will be available.