Score:0

Oracle 18c XE can't backup PDB database after corruption of the main XE database

in flag

I have an Oracle 18c XE server where there is a corruption in the system01.dbf file of the main XE database.

All user data is in a PDB database which luckily seems ok (the PDB is working in production now).

The problem is that I can't make a backup of the PDB with expdp, because expdp fails with this error:

UDE-00604: operation generated ORACLE error 604
ORA-00604: errore riscontrato in SQL ricorsivo livello 2
ORA-01578: blocco dati ORACLE danneggiato (file # 1, blocco # 636)
ORA-01110: file di dati 1: '/opt/oracle/oradata/XE/system01.dbf'

Similarly I can't connect with RMAN, because of the same error:

RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-00554: initialization of internal recovery manager package failed
RMAN-04005: error from target database:
ORA-00604: errore riscontrato in SQL ricorsivo livello 2
ORA-01578: blocco dati ORACLE danneggiato (file # 1, blocco # 636)
ORA-01110: file di dati 1: '/opt/oracle/oradata/XE/system01.dbf'
RMAN-04015: error setting target database character set to US7ASCII

For simplicity, I would just like to backup the PDB, then delete and reinstall the whole 18c XE database from scratch and then restore the PDB (no need to recover anything, since the corruption is in the main XE database, while the PDB is ok).

Is there a way to do this?

I have no previous RMAN backups, since I have always made all backups with expdp, but backups are old now, because expdp stopped working some days ago when the corruption probably happened.

UPDATE

In the end the only viable solution was:

  • Install Oracle 18c XE on another machine
  • Restore the db schema without rows on the new machine from an old expdp dump
  • Create a database link from the new machine to the original server with the running PDB
  • manually INSERT INTO ... SELECT all tables from the original linked server to the new machine
  • make an expdp dump from the new machine
  • reinstall Oracle on the original server and import the newly created dump
Gerard H. Pille avatar
in flag
I can't help you, being out of touch with Oracle, but a word of advice: don't shut down the production database. Does the old export (exp) still work, or do you have datatypes it can't handle?
in flag
@GerardH.Pille Thanks for the advice, but I already shut down and restart the old database multiple times. It still works, luckily, probably because the corruption is in the main XE db and not the PDB. I just can't export and also I can't list PDB tables in sqldeveloper, but the tables are working (it's an ERP and people are using it). The old export would definitely work, I'm pretty sure, but since it's old and the current production database is still working and being updated, I'd like to find if there's a better way to save the current database than reverting to an old backup.
Gerard H. Pille avatar
in flag
I'd use the old exp program to export the current data, if there isn't a better solution.
in flag
@GerardH.Pille I just tried, but exp gives the same error as expdp. Tonight I'll try some more block recover on the main XE database after backupping the whole folder as is.
Score:1
cn flag

The system tablespace (system01.dbf) includes data dictionary objects that are shared by both the container and pluggable databases. You can't backup the PDB shouldn't be able to open it for access without the CDB running. I believe you will need to restore the system tablespace from an earlier RMAN backup before you can make a new backup of the PDB or unplug it.

See here for further direction: https://oracle-base.com/articles/12c/multitenant-rman-backup-recovery-cdb-and-pdb-12cr1#cdb-recovery

in flag
Unfortunately I don't have RMAN backups, only expdp. I'll try BBED as last resort.
mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.