Network Security Internet Technology Development Database Servers Mobile Phone Android Software Apple Software Computer Software News IT Information

In addition to Weibo, there is also WeChat

Please pay attention

WeChat public account

Shulou

Rman migration point-in-time recovery

2025-01-18 Update From: SLTechnology News&Howtos shulou NAV: SLTechnology News&Howtos > Database >

Share

Shulou(Shulou.com)06/01 Report--

I was supposed to take a day off today, but when I was having dinner at 8 p.m., the supervisor called me to restore a database. At 12:00, the developers improperly operated. One of the schema was used to receive data from other factories, which made a mess.

~

Let me restore the data at around 12:00 today, but there is no problem with the other schema. I only restore this one schema, which is 1.7T database. It suddenly occurred to me that this server is a RAC,1 node data pump backup at 12:00 and a rman backup at 8pm on two nodes.

Immediately after the meal to find 1 node backup,-_ | | found to be empty, the backup script has a problem.

You can only use rman to recover ~ immediately go to 2 nodes to copy the backup of last night and the archives of yesterday and today, copy to the new server, and start the recovery, which is equivalent to the migration of RAC to a single node.

Here are the steps

The installation of the database software will be completed soon.

Copy the init.ora files of other single instance databases and start them to nomunt

Modify the database name and path location in the init file

Direct start

SQL > STARTUP NOMOUNT

Then rman enters the rman management interface to recover the control file

Restore the control file:

RMAN > RESTORE CONTROLFILE FROM'/ oradata/backup/CTCNZQF/cntrl_540843_1_962057699'

Register the backup directory to the control file.-register the copied backup file directory to the control file and tell the control file that my backup is in this directory.

RMAN > CATALOG START WITH'/ oradata/backup/CTCNZQF/'

Start the data to MOUNT

RMAN > alter database mount

Then start restore to restore the data files, but because my RAC is managed by ASM storage, it is now a local file

You need to change the data file name, so you need to newname it.

Use the following statement to find out all the data files and change them to local file names

SQL > select 'SET NEWNAME FOR DATAFILE' | | file# | |'to'| |'| | name | |'; 'from v$datafile |

Then copy the result on the text, change the name of the data file and start restore.

RMAN > run {allocate channel D1 type disk;allocate channel d2 type disk;allocate channel d3 type disk;allocate channel d4 type disk;set newname for datafile 1 to'/ oradata/CTCNZQF/system01.dbf';set newname for datafile 2 to'/ oradata/CTCNZQF/sysaux02.dbf'; set newname for datafile 667 to'/ oradata/CTCNZQF/ctcnzjf_n648.dbf';set newname for datafile 668 to'/ oradata/CTCNZQF/farmbjhs_idx649.dbf';restore database;switch datafile all Release channel d4flex release channel d3 bang release channel d2ten release channel d1;}

An error was reported during the first execution, and the data file was not restored to the specified location. I don't know why it was executed again, and the data file was restored.

And then start recovery.

[oracle@stat ~] $export NLS_DATE_FORMAT='yyyy-mm-dd hh34:mi:ss' specifies the time format

RMAN > recover database until time '2017-12-07 12 0015 56' specify the time to restore

Then report an error and indicate that it is not filed.

But my archive has been copied to the directory I wrote.

After checking for a long time, I found out that because the control file does not know where the file is filed, it only knows backup. If I do not return to 12:00 at noon, recovery will be able to return to the state it was at 8 o'clock last night, so he wants to file from 8pm to 12:00. He can't find it.

Then register, write the archive path information into the control file, and can't find out how to register the entire archive directory. Can only be pasted one by one.

Register the copied archive log to the control file and register all the latest copied archive log into the control file one by one.

RMAN > catalog archivelog'/ oradata/arch/CTCNZQF/thread_2_seq_92815.28569.962057619'

RMAN > Don't write so much because there's too much.

RMAN > catalog archivelog'/ oradata/arch/CTCNZQF/thread_2_seq_93639.8125.962135299'

And then re-execute

RMAN > recover database until time '2017-12-07 12 0015 56'

This picture shows that it is being restored.

The hint has been restored to 12:06. It means the recovery has been successful.

Then add the log group, change the name of the log group, and find all the log names in the database

Select 'alter database rename file''| | member | | Q' ['to'/ oradata/fast_recovery_area/CTCNZQF/redo';] 'from v$logfile

After changing the name. Execution

Alter database rename file'+ ASM_REDO1/CTCNZQF/ONLINELOG/group_1.257.954793817' to'/ oradata/fast_recovery_area/CTCNZQF/redo1'

Alter database rename file'+ ASM_REDO2/CTCNZQF/ONLINELOG/group_1.258.954793817' to'/ oradata/fast_recovery_area/CTCNZQF/redo2'

Alter database rename file'+ ASM_REDO1/CTCNZQF/ONLINELOG/group_24.277.955022759' to'/ oradata/fast_recovery_area/CTCNZQF/redo31'

Alter database rename file'+ ASM_REDO2/CTCNZQF/ONLINELOG/group_24.282.955022759' to'/ oradata/fast_recovery_area/CTCNZQF/redo32'

Completed ~ start the database

RMAN > alter database open resetlogs

When you want to open the data, reset the redo log and set the sequence of the redo log to zero.

SQl > create spfile from pfile; creates the spfile file.

Then I was shocked to find that there was a series of errors in the alter log, and the message was a temporary tablespace.

Because there are no temporary files during recovery, the database does not have temporary tablespaces. Rebuild ~ ~

Because the control file record says that the temp tablespace already exists, create the temp1 temporary tablespace, set temp1 to the default, delete the temp, and then recreate the TEMP. Set to delete temp by default

Create temp1 tablespace

CREATE TEMPORARY TABLESPACE TEMP1 TEMPFILE'/ oradata/CTCNZQF/temp01.dbf' SIZE 1024 m

,'/ oradata/CTCNZQF/temp02.dbf' SIZE 1024 m SIZE SIZE 1024 m

AUTOEXTEND ON NEXT 10 m MAXSIZE UNLIMITED

-change temporary tablespace to TEMP1

ALTER DATABASE DEFAULT TEMPORARY TABLESPACE TEMP1

Delete TEMP tablespace

DROP TABLESPACE temp1 INCLUDING CONTENTS AND DATAFILES

Create TEMP tablespaces:

CREATE TEMPORARY TABLESPACE TEMP1 TEMPFILE'/ oradata/CTCNZQF/temp01.dbf' SIZE 1024 m

,'/ oradata/CTCNZQF/temp02.dbf' SIZE 1024 m SIZE SIZE 1024 m

AUTOEXTEND ON NEXT 10 m MAXSIZE UNLIMITED

Change temporary tablespace to TEMP

ALTER DATABASE DEFAULT TEMPORARY TABLESPACE TEMP

Delete the TEMP1 tablespace.

After two days, ok finally finished it. It took 10 hours for restore to take this step.

If I had a 1-node data pump backup, I could restore a schema alone without having to bother for two days.

So the most important thing is to backup, and more importantly, to check the backup status.

All that's left is for the developers to sort out the data by themselves.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.

Views: 0

*The comments in the above article only represent the author's personal views and do not represent the views and positions of this website. If you have more insights, please feel free to contribute and share.

Share To

Wechat

© 2024 shulou.com SLNews company. All rights reserved.

12
Report