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

In the process of migrating Oracle database, we will encounter many situations, such as the database under 32-bit operating system is migrated to 64-bit, and the migration between different operating system platforms, so how to choose the migration tool? first of all, we need to confirm the environment of the source and target side of the migration, the downtime again, the amount of data, relatively speaking, the logical migration is a little more secure. Problems such as high water levels, such as OGG, will also be alleviated, whether by manual expdp/impdp or with the help of other tools. Rman is also a tool, so when to choose, or the pros and cons of the choice? There are a lot of version restrictions and bug, and rman can completely copy the environment of the database, which is needed in some scenarios.

Here's a test. Source environment: Windows2008 64-bit + Oracle11.2.0.1+ filesystem

Destination environment: Redhat6.7 x64+oracle11.2.0.4+ASM

First, let's confirm the bytes:

Let's start the migration through rman

Perform a backup in a Windows environment:

Generate the pfile file with the following statement:

Create pfile='d:\ pfile20171029.ora' from spfile

Copy backup files, archive logs, pfile files, and password files to the destination side (Linux)

Related actions on the destination side:

First, edit the parameter file, modify the relevant paths, parameters, etc., and create the relevant directory

For example:

Mkdir-p / home/oracle/archivelog

Mkdir-p / u02/app/oracle/admin/orcl/adump

Start the database to nomount state

Export ORACLE_SID=orcl

Sqlplus / as sysdba

Startup nomount pfile='/home/oracle/rmanbackup/pfile20171029.ora'

Start restoring the control file (note that the changed control file in the initialization parameter file is stored on ASM disk)

* restore the control file and start to the mount phase:

* register backup files

To restore the database, note here that the invalid backup in rman needs to be cleaned first. If it is not cleaned, it needs to be made, otherwise the original backup will be found first, as shown below:

* check backups are performed here and clean up invalid and expired backups (diagram)

Perform the restore operation again:

OK, we execute recover.

Recovery Manager complete. Note here that recover database is executed here, and the archive log is not applied. Furthermore, the online log does not have the original directory, and the database open will be created to the dbs directory by default. After open, you need to change the redo log location.

Recover is complete, let's start open

SQL > alter database open resetlogs upgrade;-- upgrade version from 11201 to 11204

Database altered.

It's open. All right, are we done? Redo log didn't do it, what else do you think about it?

First of all, we need to make the database exactly right, to execute a few scripts to complete the final database upgrade.

The following three scripts need to be executed, sequentially, first catupgrd.sql, then utlrp.sql catbundle.sql

One more thing to note: before executing catupgrd.sql, you need to rebuild the temporary tablespace as follows:

Create temporary tablespace temp01 tempfile'+ DATA' SIZE 1G

Alter database default temporary tablespace temp01

Drop tablespace temp including contents and datafiles cascade constraints

Ok, it's ready to execute.

SQL > @? / rdbms/admin/catbundle.sql psu apply

SQL > @? / rdbms/admin/utlrp.sql

SQL > @? / rdbms/admin/catupgrd.sql-- the first to execute, it will frequently switch archives, my test space has exploded

Why do you need to execute these three? let's take a look at the descriptions of these scripts.

First, the main purpose is to update the patch information to sql and perform something else, that is, the view dba_registry_history

Second, recompile invalid objects

The final thing is the third, which must be executed. Here we are talking about version 10.2 and before. This environment is 11.2.0.1 to 11.2.0.4. It is also a script that must be executed. If you do not want to need alter database open upgrade every time after shutdown database, then perform this step.

After the execution of the script, let's take a look at the version information:

The red part is part of the upgrade and can be ignored. The second behavior executes script catupgrd.sql generation, description information: Upgraded from 11.2.0.1.0

The execution result of the third behavior script catbundle.sql

Is there any final work? by the way, the online log path hasn't changed yet, so check it out.

The basic steps are as follows:

Select group#,status from v$log

Alter system archive log current

Alter database drop logfile group 3

Alter database add logfile group 3 ('+ DATA') size 100m

Alter database drop logfile group 1

Alter database add logfile group 1 ('+ DATA') size 100m

Alter database drop logfile group 2

Alter database add logfile group 2 ('+ DATA') size 100m

When the change is complete, you also need to execute the following command

Create spfile from pfile='/home/oracle/rmanbackup/pfile01.ora'

Restart the database verification again, and the database is normal.

Wait, we need to add archive logs to recover...

Read the archive log and reported an error, and finally used the failure mentioned in the MOS article, so what if the source and target archive logs are stored in ASM mode? Will it show up? Keep it. You can't use additional archive logs. Just use incremental backups.

Although it seems simple to use logical migration, such as expdp/impdp, there are actually a lot of things to prepare. If you are interested, you can test it. We may encounter different operating systems, different versions, or even 32-bit to 64-bit when migrating. I wonder if Oracle18C can solve it?

Tossing about for a long time, and finally ended with 600, it is also considered no regrets, in fact, it is quite nonsense.

That's it. Have a nice Monday.

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.